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PREFACE 


In  1973  the  Air  Force  initiated  an  advanced  development  project 
witnin  tne  Electronics  systens  Command  (AFSC/ESD)  to  acquire  ana 
apply  the  1S0U3  Project  (University  "of  Michigan  1  Problem 
Statement  Language/  Problem  statement  Analyzer  (PSL/PSA)  to  ESL 
requirements  analysis  needs.  The  Air  Force  version  of  PSL/PSA 
was  accepted  oy  ESD  in  1974  ana  was  called  tne  user  Requirements 
Language/User  Requirements  Analyzer  (URL/URA)*.  in  19 7 S  Logicon 
performed  an  evaluation  for  the  ESD  Joint  surveillance  System 
(jss)  program  office  on  the  applicability  of  URL/ura  as  a  tool 
tor  both  tne  analysis  of  JSS  requirements  and  tne  aesign  of  tne 
JSS.  as  a  result  of  tne  JSS  study,  Logicon  began  to  use  URL/URA 
In  its  system  engineering  support  role  to  JSS  ana  Is  continuing 
tne  use  of  the  tool  in  the  development  phase  of  tne  JSS  at  this 
time. 

During  the  past  five  years  Logicon  has  broadened  its  experience 
using  uhu/ura.  Additional  stuales,  applications ,  and  training 
programs  for  industry  and  government  nave  been  performed.  A 
formalized  approach  has  been  developed  by  Logicon  tor  applying 
ukl/ura  and  Logicon  has  extended  URL/URA  under  contract  to  the 
Air  Force.  In  addition,  Logicon  has  independently  translated  ana 
installed  URL/URA  and  the  Logicon  extensions  and  moaif lcations  on 
the  Logicon  VAX  11/ 7 HO  system  in  Lexington,  M A .  Additional 
extensions  for  such  applications  as  automated  specif ication 
documentation  generation  from  the  URL/URA  data  oases  have  been 
aevelopea  and  applied  to  new  projects  within  the  past  year. 

This  guidebook  was.  developed  under  contract  to  the  U.S.  Army 
Computer  Systems  Command  (USACSC),  Army  Institute  tor  Research  In 
Management  information  and  Computer  Science  (AlRMlCS).  it  is  tne 
second  of  a  two  volume  report  for  USACSC  arid  "has  been  prepared  to 
aid  the  systems  requirements  definition’  and  analysis  process 
(requirements  engineering  3  witnin  USACSC.  Guidelines  ana 
standards  for  requirements  engineering  and  tne  use  ot  PSL/PSA  are 
presented  in  this  guidebook. 


*  UR1./URA  was  also  previously  called  tne  Computer-Aided 
Requirements  Analyzer  (CARA)  by  the  Air  Force.  URL/URA  is 
currently  referred  to  as  the  Computer-Aided  Design, specif ication, 
and  Analysis  Tool  (CADSAl'J  by  the  Air  Force. 
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SECriJN  1  INTRODUCTION 


1 . i  Purpose 


l  n  1  s  requirements  engineering  guidebook  provides  guidance  and 
standards  for  aetining  ana  analyzing  the  requirements  tor  a 
system  using  an  automated  tool  (PSL/PSA) .  Inis  guidebook 
addresses  the  modeling  of  tne  functional  requirements  of  a  system 
(logical  modeling)  during  tne  initial  phases  of  a  system 
acquisition,  tne  definition  phase.  The  guidance  can  be  applied 
to  large-scale  as  well  as  smaller,  less  complex  systems  and  can 
oe  used  in  various  acquisition  environments. 


1.2  Scope 


i'his  guidebook  is  compatable  witn  modern  structured  approaches  to 
requirements  definition  and  analysis  and  provides  guidance  on  the 
selected  use  of  PSL/PSA.  References  to  documentation  on  various 
modern  structured  approaches  and  to  PSL/PSA  ore  provided.  Ihe 
user  of  this  guidebook  may  follow  the  approach  presented  herein 
or  tailor  the  approach  to  emphasize  a  particular  feature  of  any 
of  the  modern  structured  analysis  methods  cited  in  Appendix  A. 


l.J  Definitions 


1.1.1  System 

A  composite  of  items,  assemblies,  skills,  and  techniques  capable 
of  performing  and/or  supporting  a  using  organizations'  needs.  A 
complete  system  Includes  related'  facilities,  items,  material, 
services,  and  personnel  required  for  its  operation  to  the  degree 
that  it  can  be  considered  a  self-sufficient  item  in  its  intended 
use . 

1 .1.2  Pequirenents  Engineering 

Requirements  Engineering  is  an  Iterative  process  of  defining  the 
system  requirements  and  analyzing  the  integrity  of  the 
requirements.  This  process  involves  ail  areas  of  system 
development  preceding  tne  actual  design  of  tne  system.  The 
products  of  tne  requirements  engineering  process  can  be  evaluated 
tor  completeness,  consistency,  testability,  and  traceaoilty.  The 
essential  goal  of  requirements  engineering  is  ’to  thoroughly 
evaluate  the  needs  whicn  the  system  must  satisfy. 
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1.J.J  Quality  Requirements 

1'ne  tern  'quality  requirements'  Is  used  throughout  this  guidebook 
to  denote  system  requirements  whjcn  are  complete,  consistent, 
testable,  and  traceable.  This  characteristic  is  tne  result  of 
the  requirements  being  discretely  identified  and  *el 1-or gani ze u 
as  discussed  in  the  sections  to  follow. 


1.4  Contents 


The  remainder  of  this  guidebook  consists  of  three  sections  and 
tour  appendices,  as  follows: 


Section  2  -  Quality  Requirements  Characteristics:  Provides 
a  description  of  the  two  requirements  character istics : 
discrete  and  well  organized.  This  discussion  is  followed  by 
a  description  of  three  forms  of  well-organized  requirements: 
hierarchical  structures,  system  flows,  ana  requirements 
traceaDillty. 

Section  3  -  Structured  Approaches  and  Automated  Tools: 
Briefly  describes  the  trend  In  structured  analysis 
approaches  and  the  use  of  an  automated  tool,  PSL/PSA.  The 
utility  of  PSL/PSA  as  a  requirements  engineering  tool  is 
presented  along  with  the  various  versions  of  PSL/PSA. 

section  4  -  Requirements  Engineering  Procedures:  Provides 
the  procedural  framework  for  defining  and  analyzing  system 
requirements.  The  procedures  consist  of' fifteen  activities 
which  are  explained  in  functional  terms:  namely,  activities 
to  be  performea  by  requirements  engineers.  The  language  and 
report  features  of  PSL/PSA  which  support  each  activity  are 
presented. 

Appendix  A  -  Selected  References:  Provides  a  list  of 
references  primarily  consisting  of  structured  approacnes  to 
requirements  engineering  and  references  of  the  pertinent 
versions  of  PSL/PSA. 

Appendix  B  -  Selected  Language  Features:  Provides  a 
condensed  list  of  PSL  features  wnicn  support  the 
requirements  engineering  activities  presented  in  Section  4. 
Cross  references  are  provided  to  Section  4  and  to  the 
various  versions  of  PSL. 

Appendix  c  -  Analyzer  Reports:  Provides  a  list  of  PSA 
reports  which  support  the  requirements  engineering 
activities  presented  in  Section  4.  Cross  references  are 
provided  to  section  4  and  to  the  various  versions  of  PSA. 
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Appendix  D  -  Example  Analyzer  Reports:  provides  examples 
some  ot  Lne  PSA  reports  described  in  Appendix  C. 
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l . 1  introduction 


Quality  requirements  are  dependent  upon  tne  analyst  first 
identifying  tne  discrete  requirements  of  tne  system  ana  tnen 
organizing  tnese  requirements  in  effective  ways  for  furtner 
analysis.  ine  resulting  organization  is  often  rererrea  to  as  a 
functional  or  logical  model,  wnere  tne  ODjects  in  tne  model  and 
their  relationsnips  to  eacn  otner  provide  a  comprehensive 
description  (specification)  of  tne  user  needs. 


Initial  documentation  for  identifying  tne  user's  system 
requirements  may  include  early  planning  documents  and 
specifications  for  similar  systems,  for  system  interfaces,  ana 
for  existing  or  previously  defined  subsystems.  In  addition, 
documentation  derived  from  engineering  studies  and  prototyping  or 
experimental  test  systems  may  oe  available.  if  tne  engineering 
activities  nave  advanced  beyond  tne  planning  and  study  stage, 
specification  documents  may  nave  already  oeen  developed.  Tnese 
early  requirements  documents  usually  nave  one  prevailing 
cnar acter istic :  The  system  requirements  are  not  typically 
distinguisned  (discrete)  or  collectively  defined 
(well-organized)  . 


i.'l  Discrete  Requirements 


Figure  1  illustrates  the  first  characteristic  of  quality 
requirements:  discreteness.  Tne  Key  to  identifying  discrete 
requirements  is  to  break  the  user  needs  into  individual  parts 
(objects)  whicn  represent  non-overlapping  requirements.  Discrete 
requirements  include  system  objects  (functions,  external  and 
internal  inputs  and  outputs,  etc.)  and  properties  (statements 
aoout  the  oojects)  such  as  constraints  ana  descriptions.  At  this 
point  missing  or  incomplete  requirements  can  oe  more  readily 
Identified.  Xnis  itemization  and  categorization  of  requirements 
Introduces  clarity,  whereas  the  sources  of  the  requirements  may 
be  overstated,  ambiguous,  redundant,  incomplete,  and 
Inconsistent.  This  process  of  itemization  also  provides  tne 
basis  tor  verifying  the  quality  of  the  requirements  and  tor 
assessing  the  ability  to  test  the  requirements  in  the  target 
system. 
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2-J  t'ry  anizat  ion  ot  Requirements 


Tne  seconu  cnaracteris t ic  ot  a  good  statement  ot  requirements  is 
the  arrangement  of  the  requirements  in  effective  ways  for 
additional  analysis  and  tor  communicating  tnese  requirements  to 
tne  using  agency  and  to  design  engineers.  me  Identification  of 
discrete  requirements  provides  some  awareness  of  omissions  and 
gaps  in  the  requirements.  This  awareness  is  turtner  neigntened 
oy  organizing  the  requirements  in  ways  whicn  identity  ail  tne 
relationsnips  among  the  discrete  requirements  (Figure  l).  These 
relationships  are  of  three  types:  hierarchical  organizational 
relationsnips,  system  flow  relationsnips,  and  requirements 
traceability  relationsnips.  The  following  paragraphs  discuss 
these  relationships. 


2.3.1  Hierarchical  organizational  Relationships 


Hierarchical  organizational  relationships  are  shown  by 
structuring  tne  discrete  functions  and  tne  information 
requirements  (external  and  internal  inputs  ann  outputs)  of  tne 
system  into  hierarchical  structures.  Tne  concept  ot  a  functional 
hierarchical  structure  (Figure  2)  was  Introduced  into  military 
systems  development  tnrough  initial  systems  engineering  practices 
dating  back,  to  tne  1940s.  This  concept  has  been  maintained  in 
military  systems  development  and  documentation  throughout  the 
19t>Us  and  is  an  integral  part  of  ' the  current  military  standards 
for  system  documentation,  i.e.,  Dot)  Standard  793b. 1-s  (lj’and 
Ml L-STD-490  [2J.  This  form  of  organization  provides  a  view  of 
the  system  as  an  aggregate  of  functions  oroken  into  a  logical 
arrangement  ot  subordinate  discrete  activities  wnich  must  oe 
performed.  Over  the  course  of  requirements  engineering  many 
missing  or  incomplete  functions  can  be  directly  identified  from 
the  functional  hierarchical  structure. 

The  discrete  system  inputs,  outputs  (external  l/U)  ano  the 
Internal  Information  requirements  (internal  I/O)  necessary  for 
tne  system's  operation  can  be  similarly  structured  (data 
structures).  Tne  emphasis  again  Is  the  arrangement  of  the 
information  requirements  into  hierarchical  structures  oy  creaking 
the  information  into  logical  subordinate  parts  or  groupings 
(Figure  3).  A  well-organized'  data  structure  is  effective  in 
communicating  tne  information  requirements  and  tor  identifying 
incomplete  or  missing  information  requirements. 
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SYSTEM-NAME 


Figure  ?.  Functional  Hierarchical  Structure 
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SYSTEM  I/O 


SYSTEM  I/O 

INPUT-A  ... 
OUTPUT-B 

BA  ... 

BB 

BBA  . . . 
BBB  . . . 
BBC  ... 
(etc) 

BC  ... 
(etc) 

INPUT-C  ... 
OUTPUT-D  ... 
(etc) 


Figure  3.  I/O  Hierarchical  Structure 
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2.i.2  System  flow  H  e  1  at  Ions  nips 


System  flow  relationships  can  be  snown  by  organizing  the  discrete 
requirements  in  terms  of  control  flo*  (Figure  41  and  information 
flow  (Figure  5).  As  the  functions  of  trie  system  are  defined,  tne 
control  relationships  oetween  them  can  also  De  derinea,  These 
control  relationships  describe  the  logical  order  in  whicn  the 
system  activities  should  be  accomplished  to  satisfy  tne  system 
mission  and  operational  requirements.  Conditions  which  determine 
tne  flow  direction  when  two  or  more  branches  occur  are  also 
represented.  Control-flow  analysis  provides  a  means  of  viewing 
the  system  from  an  activity-oriented  perspective  and  is  often 
referred  to  as  functional-flow  analysis.  As  a  result  of  this 
analysis  the  requirements  are  viewed  in  a  well -organized  manner 
and  missing  or  incomplete  functions  and  relationships  between  tne 
functions  are  identified.  Final  control-flow  documentation 
becomes  another  effective  means’  for  communicating  system 
requirements  to  design  engineers. 

Un  the  other  hand,  the  information-flow  analysis  (Figure  5) 
builds  upon  tne  I/O  hierarchical  structure  (Figure  i)  by 
providing  a  means  of  viewing  tne  system  as  an  information 
processing'  system.  During  this  analysis  the  flow  relationships 
between  external  system  inputs  and  resulting  outputs  are 
identified.  Oulte  often  tne  most  effective  means  of  performing 
information-flow  analysis  is  to  trace  an  output  bacK  to  system 
inputs,  either  external  data,  messages,  or  stimuli.  As  a  result 
of  this  analysis  the  relationships  between  tne  associated 
functions  and  the  internal  information  necessary  to  support  the 
derivation  of  the  output  are  identified. 

Control-flow  and  information-flow  analysis  will  Identify 
necessary  changes  and  additions  to  previously  defined  functions 
and  constraints  as  well  as  to  the  hierarchial  structures  and 
other  previously  defined  relationships’.  Missing  or  incomplete 
requirements  can  be  determined  and  the  deficiencies  corrected. 

Requirements  engineering  for  systems  which  are  primarily  activity 
oriented  may  emphasize  control-flow  analysis  over 
information-flow  analysis.  Other  systems  may  be  primarily 
information  processing  oriented  and,  tneretore,  tne  requirements 
engineering  activities  may  concentrate  more  on  intormat lon-flow 
analysis  rather  than  control-flow  analysis.  in  eitner  case,  botn 
forms  of  analysis  are  involved  In  a  total  system  definition. 


Figure  4.  Control-Flow  Diagram 
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Figure  5.  Information-Flow  Diagram 
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H«‘guu  caenti  Traceabilty  Relationships 


ioeri  1 1 1 1  cu  tl  on  ot  system  t  r<»  ceab  l  i  i  t  y  r  ei  at  ]  ons  n  1  ps  is  .inotner 
etiectivt  means  ot  identifying  incomplete,  unnecessary  and 
mlssinq  requirements.  during  the  requirements  engineering 
activities,  source  aocunents  ae  referenced  for  eacn  requirement 
identified.  requirements  traceability  analysis  provides  the 
analyst  with  a  means  of  verifying  me  requirements  by  linking 
eacn  requirement  to  all  forms  of  source  documenta ti on .  Tnese 
links,  in  the  form  of  source  references  tsources),  provide  a  link 
Detween  the  requirements  from  one  set  of  system  requirements 
(originating  requirements)  to  the  allocated  requirements 
contained  in  tne  next  level  of  the  modeling  or  specification 
process  using  additional  references  (traces).  For  instance,  in 
Dod  Standard  7935. i-S  the  requirements 'may  be  traced  from  one 
nigher  level  specification  to  another  such  as  from  the  FO  to  SS, 
SS  to  PS  etc.,  or  in  MIL-STD-490  from  Type  A  to  Type  9 
specif icatlons .  Relationships  can  also  be  defined  to  other 
pertinent  studies,  analyses,  and  plans  whicn  are  being 
accomplished  concurrently  witn  the  requirements  engineering 
activities,  such  as  program  management  directives  and  plans, 
system  sizing  and  timing  studies,  prototyping,  simulations,  test 
planning  and  the  like.  System  test  requirements  (quality 
assurance),  as  well  as  subsequent  test  plans,  procedures,  ana 
reports,  can  be  effectively  related  to  the  functional 
specification  (originating  requirements).  Tne  links  to 
associated  system  plans,  analyses,  and  studies  accomplished  prior 
to,  during  and  subsequent  to  the  start  of  formal  requirements 
engineering  are  crucial  to  tne  overall  systems  engineering 
concept.  The  traceability  relationships  also  provide  a  bridge 
between  requirements  engineering  activities  and  subsequent  design 
and  implementing  activities,  since  the  requirements  can  be  traced 
from  higher  level  functional  (logical)  specif icatlons  to  design 
specifications,  to  product  specifications,  and  to  system  test 
plans  and  procedures  during  the  later  phases  ot  the  system 
acquisition. 

Throughout  the  system  engineering  activities,  the  analysts  must 
be  able  to  evaluate  tne  impact  of  changes  to  the  requirements. 
Whatever  the  reason  (policy',  economics,  stuay  or  analysis 
results,  new  or  modified  requirements),  the  analyst  must  be  in  a 
position  to  determine  tne  ramifications  of  cnanges  to  the  system 
requirements  as  stated  in  various  levels  of  specif lcation.  Once 
the  area  of  impact  is  identified  in  the  requirements  engineering 
products  (functional  and  I/O  hierarchies,  control  and  information 
flows,  etc.)  tne  traceability  reiationships  defined  during  the 
previous  requirements  engineering  activities  (sources  and  traces) 
provide  tne  capability  to  readily  identify  associated  impacts  to 
various  parts  of  the  system  functional  specification  (logical 
model)  and  to  trace  the  Impacts  to  all  other  associated 
documentation:  program  directives,  plans,  studies  and  analyses, 
test  plans  and  procedures,  and  allocated  specifications  (design 
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ana  product  specifications).  The  impact  can  oe  readily  analyzed 
ana  tne  appropriate  actions  taken. 


2.4  Summary 


Discrete  and  well-organized  requirements  support  tne  primary  goal 
of  defining  the  operational  needs  of  the  using  activity  while 
giving  the  analyst  visibility  and  control  over  the  system 
functional  definition  (logical  modeling)  process.  Discrete  and 
well-organized  requirements  are  prerequisites  for  tne  creation 
of  good  functional,  design,  and  product  specifications. 
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SECTION  i  STRUCTURED  APPROACHES  AND  AUTOMATED  TOOLS 


J.i  structured  Approaches 


In  recent  years  a  great  amount  of  research  ana  applications  have 
been  concentrated  on  techniques  for  defining,  analyzing,  ana 
documenting  the  requirements  for  systems.  Most  of  these 
techniques  Include  the  term  'structured'  and  are  primarily  manual 
tecnniques  1143,  [153,  [163,  [173,  [163,  [193,  1203.  Some 
structured  techniques  do  address  the  use  of  computer  aids  as  a 
means  of  maintaining  the  requirements  and  producing  documentation 
during  the  modeling  process.  The  computer  data  bases  are 
maintained  eitner  manually  or  by  automated  tools,  and,  are 
generally  referred  to  as  data  dictionaries. 


i . 2  XSDOS  Project  -  PSL/PSA 


The  University  of  Michigan's  ISDOS  Project  began  in  1968  to 
develop  a  more  advanced  computer-aided  tool  called  the  Problem 
Statement  Language/  Problem  Statement  Analyzer  [PSL/PSAJ. 
PSL/PSA  is  a  more  sophisticated  data  dictionary  tool  whlcn 
provides  the  capability  to  record  in  an  English-like  language 
IPSLJ  the  various  objects  (functions  ,  Inputs,  outputs,  etc.)  of 
a  system  being  defined  (the  target  system)  and  r  iationshlps 
between  the  objects  (hierarchy,  flow,  etc.).  The  objects  and 
relationships  are  maintained  in  a  computer  data  base  called  a 
requirements  data  base  or  PSL/PSA  data  base.  Tne  requirements 
data  base  can  be  used  by  the  analyzer  (PSA)  to  generate  various 
reports  about  the  target  system  such  as  hierarchical  structures 
(functional  and  data),  system  flow  (control  and  Information)  and 
many  others. 

Since  the  early  1970s,  PSL/PSA  has  been  applied  by  a  large  number 
ot  users  with  varying  degrees  of  success.  Althougn' the  tool  is  a 
very  sophisticated  software  tool,  there  is  no  recommended 
approach  for  using  it  in  developing  logical  models.  Inis  may  oe 
due  in  part  to  the  research  and  aeve looment  nature  ot  the  ISDOS 
Project  or  possibly  a  greater  desire  to  make  tne  tool  a  more 
general  purpose  product  and  thereby  attract  a  larger  number  of 
PSL/PSA  users.  Many  of  the  desired  capabilities  ot  tne 
structured  approaches  being  practiced  today'  are  not  easily 
satisfied  using  PSL/PSA.  Studies  of  PSL/PSA  for  large  systems 
definitions  nave  documented  the  need  for  Improvements  and  some 
Improvements  nave  been  incorporated  in  new  versions  (3)  ,  [4]  . 
Some  of  tnese  Improvements  have  been  made  as  part  of  tne  ISDOS 
Project  and  some  nave  Deen  made  independently  by  various  PSL/PSA 
users  to  meet  specific  modeling  needs  [53. 
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3.3  Utility  of  PSL/PSA 

Various  versions  of  PSL/PSA  are  currently  being  usea  in  Industry 
ana  in  government  agencies  as  Indicated  below. 


(.3.2)  UKL/UftA  (CARA  UP  CADS  AT ) ,  an  Air  Force  version  of 
PSL/PSA ,  University  of  Michigan  (ISDOS  Project),  1974  16)  £7J. 

13. 2X)  3.2  plus  extensions  and  modifications  made  by  Logicon 
inc.  for  the  Air  Force,  19?6  £5], 

(4.2)  PSL/PSA  version  available  from  the  university  of 
Michigan  (ISDOS  Project),  1977-1976  £8),  £9J,  £lu). 

Ib.l)  Most  recent  version  of  PSL/PSA  available  from  the 
university  of  Michigan  (ISDOS  Project),  1978-1979  £11],  £12), 

£13). 


Although  new  versions,  specifically  5.1,  do  include  some 
recommendations  made  in  various  studies  and  by  the  ISDOS  users 
group,  the  basic  core  capabilities  of  the  tool  are  available  in 
the  earlier  releases  such  as  the  Air  Force's  version,  URL/URA. 


Learning  the  features 
(l’.e.,  learning  to 
time  consuming.  The  n 
one  to  six  month 
computer-aided  techniq 
and  training  documen 
varies  in  quality,  is 
size  and  presentation 
the  new  user.  The  new 
language  or  report  f 
best  suited  to  his  nee 


of  PSL/PSA  as  a  software  system  alone 
use  tne  language  and  reports)  is  in  itself 
ew  user  may  become' generally  proficient  in 
s  depending  upon  his  experience  with 
ues  and  the  quality  of  available  training 
tatlon.  Documentation  on  the  tool,  which 
generally  for  reference  purposes  and  the 
of  the  material  is  most  often  perplexing  to 
PSL/PSA’  user  will  often  wonder  why  a 
eature  is  available  and  also  which  ones  are 
ds . 


Even  after  the  tool  features  are  rea 
user  must  tnen  determine  the  best 
to  nls  requirements  engineering 
numerous  structured  approaches  oe 
cooe  with  the  additional  problem  of 
approach  is  best  suited  to  his  requ 
it  the  new  user  is  unfamiliar  with  a 
must  become  familiar  with  the  n 
perplexities  of  the  new  user  can  o 
PSL/PSA,  (2)  learning  and/or  d 
approach  to  apply,  (3)  and  most 
analyzing  the  target  system. 


sonaoly  understood, 
approacn  to  applying 
problem.  since  th 
lng  expounded,  tne 
determining  wnicn  s 
irements  engineering 
ny  structured  appr 
ew  analysis  tecnniq 
e  threefold:  ci) 

etermining  which  s 
importantly  -  defi 
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J .  ‘l  Guidelines  tor  Requirements  tngineermg  using  RGL/PSA 


in  is  guidebook  Has  been  prepared  to  assist  tne  ne*  user  ot 
PSt/PSA  in  applying  the  tool  In  a  productive  manner  to  tne 
logical  modeling  ot  a  target  system.  Tnis  metnoaoiogy  was  first 
documented  as  part  o£  Loglco: 's  final  tecnnical  report  tor  tne 
KADC  Requirements  Standards  Stua,  (RSS)  Li).  The  RSS  provided  an 
approach  to  requirements  definition  and  analysis  and  among  other 
study  results  provided  a  description'  of  the  functional 
capabilities  of  automated  requirements  analysis  tools. 

Tne  guidance  provided  in  tnis  guiaebook  Is  intended  to  aid  the 
new  as  well  as  the  experienced  PSL/PSA  user  Dy  providing  a 
structured  approach  to  the  logical  modeling  process  and  to 
identity  the  current  features  of  PSL/PSA  which  are  pest  suited  to 
the  loqical  modeling  activities  described.  Theuser  is  expected 
to  use  the  references  in  appendices,  especially  those  tor  the 
version  of  PSL/PSA  oeing  employed,  for  more  detailed  examples  ot 
the  language  and  report  features  of  PSL/PSA.  The  Intent  of  this 
guidebook  is  to  provide  the  framework  for  requirements 
engineering  and  an  overview  of  the  utility  of  PSL/PSA  to  support 
the  logical  modeling  process. 
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SECTION  4  REQUIREMENTS  ENGINEERING  PKUCELiUHHS 


4.1  introduction 


Tne  use  of  PSL/PSA  must  be  restricted  oy  a  particular 
requirements  engineering  approach.  A  poorly  defined  or 
inadequate  approach  will  result  in  co:  tly  and  inadequate  results. 
Conversely  a  well  defined  approach  enhanced  through  utilization 
of  selective  features  of  a  tool  sucn  as  PSL/PSA  will  result  in 
specifications  of  consistently  higher  quality.  A  well-defined 
approach  and  selected  use  PSL/PSA  as  presented  In  this  guidebook 
is  strongly  advised. 

Requirements  engineering  is  tne  method  used  to  derive  and 
document  quality  system  requirements.  Requirements  engineering 
as  used  in  this  guiaeboo<  Is  defined  as  follows: 


Requirements  Engineering  is  an  iterative  process  of 
defining  the  system  requirements  and  analyzing  the 
integrity  of  the  requirements.  This  process  involves  all 
areas  of  system  development  preceding  the  actual  aesiyn  of 
the  system.  The  products  of  the  requirements  'engineering 
process  can  be  evaluated  for  completeness,  consistency, 
testability,  and  traceability.  The  essential  goal  of 
requirements  engineering  is  to  thoroughly  evaluate  tne 
needs  which  tne  system  must  satisfy.  Requirements 
engineering  is  principally  concerned  with  the  initial 
phases  of  tne  system  acquisition  life  cycle;  l.e.,  the 
definition  phase. 


Requirements  engineering  begins  by  Identifying  system  boundaries 
and  defining  tne  system  in  terms  of  functional  and  constraint 
requirements.  A  functional  requirement  (function)  is  the 
statement  of  a  need  whicn  must  oe  fulfilled;  a  constraint 
requirement  is  a  restriction  on  the  function(s)  which  allows  a 
solution  to  oe  derived.  Constraints  fall  into  one  of  the 
categories  as  illustrated  in  table  1. 

In  oer forming  requirements  engineering,  t unctions  and  their 
constraints  as  well  as  other  requirements  described  in  this 
section  are  extracted  from  source  documents.  These  requirements 
can  then  be  organized  Into  hierarchical  structures  wmch  reveal 
gaps  which  may  be  hidden  cy  tne  overlapping  and  confusing 
statements  of  the  original  sources.  Control  ana 
lntormatlon-f lows  can  also  be  explicitly  defined  to  make  tne 
functlon-to-f unction  ana  f unction-to-system  data  interactions 
visible.  Finally,  requirements  can  be  traced  from  originating 
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Table  l.  System  Requirement  Types 


FUNCTIONAL 

REQUIREMENTS 

(functions) 

The  set  of  discrete  functions  which 
identify  the  pure  design  free  or 
solution  independent  needs  of  the  system 
as  a  whole.  The  functional  requirements 
identify  what  must  be  accomplished  while 
avoiding  solution  statements  or  overtones. 

How  well  the  system 
PERFORMANCE  functions  must  be 

accompli  shed, such  as 
timeliness  and  accuracy. 
Also  called  performance 
characteristics, 
MIL-STD-490. 

SYSTEM 

REQUIREMENTS 

CONSTRAINT 

REQUIREMENTS 

Influences  the  design 
solution  in  a  physical 
PHYSICAL  manner:  power,  size, 

weight,  environment, 
human  factors,  existing 
system  interfaces,  GFP, 
etc.  Also  called 

Physical  Characteris¬ 
tics,  MIL-STD-490. 

■Reliability,  maintain- 
OPERABILITY  ability,  availability, 

dependability. 

(Constraints) 

Identify  the  functional, 
performance,  physical, 
TEST  operability,  and 

design  requirements 
which  will  be  evaluated 
during  .system  integra¬ 
tion  and  test. 

The  minimum  or  essen¬ 
tial  design  and 
construction  require¬ 
ments  which  are  a 
constraint  on  the 
functional  require- 
DESIGN  ments  of  the  system 

during  the  design  and 
construction  of  the 
system  end- items 
(CIs/  CPCIs).  Also 
called  Design  and 
Construction,  MIL-STD- 
490. 

if 
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source  aocunients  tnrougn  various  levels  of  system  specifications 
to  verity  tnat  all  requirements  nave  oeen  allocated  ana 
implemented  in  tne  delivered  system. 

As  stated  in  tne  definition  above,  requirements  engineering  is  an 
iterative  process  of  defining  tne  system  requirements  and 
analyzing  tne  integrity  of  the  requirements  for  completeness, 
consistency,  testability,  ana  traceability  (Figure  t>J.  As  tr.e 
process  continues  the  system  requirements  are  defined  ana 
analyzed  in  a  progressively  expanding  manner.  Tne  definition  and 
analysis  activities  will  move  from  one  area  of  concentration  to 
anotner  as  tne  results  of  previous  activities  reveal  areas 
neeaing  additional  work.  iio  single  approacn  can  De  rigidly 
deiined  and  applied  wnlch  can  take  into  account  tne  many 
possibilities  ithicn  must  oe  considered.  However,  guidelines  tor 
requirements  engineering  and  associated  tas<s  can  be  defined  ana 
tnen  tailored  for  specific  requirements  engineering  applications. 

This  section  presents  a  general  framework  for  requirements 
engineering  as  illustrated  in  Figure  7  as  well  as  recommenced 
PS b/ PSA  language  and  report  features  wnich  can  oe  applied  to  each 
activity  IBLOCKJ.  E'ach  block  represents  a  unique '  activity  wnicn 
can  be  accomplished  in  defininy  and  analyzing  system 
requirements.  There  is  a  continual  interaction  between  the 
activities  of  each  block,  and  although  each  block  appears  as  a 
single  activity,  it  is  in  fact  part  of  a  continuum,  me 
selection  of  an  actual  approach  for  a  qiven  application  is  one  of 
the  tasks  (BLOCK  2] .  In  a  given  application,  not  ail  Dlocks  will 
necessarily  be  performed.  The  blocks  selectea  must  oe  responsive 
to  the  resources  available  to  the  project  and  tne  objectives  of 
tne  analysis  staff.  The  following  is  a  orief  description  of  each 
of  the  15  Diocks  portrayed  in  Figure  7. 


BLOCK  1  Identify  and  Review  Source  Documentation:  The  analysis 
team  becomes  familiar  with  the  problem  and  all 
pertinent  background  information. 

BLOCK  2  Produce  Requirements  Lngineering  Plan:  A  plan  is 

developed  to  define  the  activities  to  oe  accomplished 
during  BLGCKS  3-ld;  i.e.,  project  schedule,  tool 

features  to  be  used,  quality  assurance  provisions,  etc. 

h LUCK  J  identity  System  functions:  System  tunctions  are 

identified  in  the  source  documentation  and  formally 
defined. 


BLOCK  4  organize  Functions  into  a  Hierarchical  Structure:  l'ne 

functions  in  BLOCK  d  are  organized  so  that  eacn  higher- 
level  function  is  represented  as  an  aggregate  of  more 
detailed  functions. 
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BLOCK 


bLQCK 


BLOCK 


BLOCK 


6LUCK 


BLOCK 


BLOCK 


BLOCK 


BLOCK 


BLOCK 


BLOCK 


5  Identity  System  Constraints:  Constraints  for  the 

functions  are  defined  where  justified  ana  attocned  to  a 
specific  function  in  tne  functional  hleraicny. 

o  identify  System  Using  Activities:  System  using 

activities  (e.g.,  organizational  units,  external 
systems)  winch  interact  with  the  system  from  outsiae 
the  system  ooundary  are  identified  and  structured 
nier archically. 

7  identify  External  System  Inputs-Qutputs  11/0):  inputs 

and  outputs  to  tne  target  system  '  are  defined 

concurrently  witn  the  using  activities. 

8  Perform  Information-Flow  Analysis:  Information  flows 

snowing  the  data  flow  between  external  inputs,  target 
system  functions,  information  witnin  tne  system,  and 
external  outputs  are  defined. 

9  Structure  system  Information:  External  and  internal 

information  is  logically  organized  (i.e.,  data 
dictionary). 

10  Perform  Control-Flow  Analysis:  The  sequences  of  system 

functions  are  defined'  as  well  as  tne  control  on  the 
flow  paths .  ' 

11  Perform  Test  Analysis:  System  requirements  which  will 

oe  subjected  to  formal  testing  and  tne  test  points  in 
trie  control  paths  are  determined. 

12  Prepare  Specification  Documentation:  Products  of  BLOCKS 

j-11  are  Incorporated  into  specification  documents  such 
as  DoD  7935. 1-S,  M1L-STD-490 ,  or  otner  approved 

formats . 

13  Perform  Traceability  Analysis:  Requirements  are  traced 
from  one  level  moael  to  another  (or  from  one 
specification  to  another)  to  ensure  that  the  subsequent 
models  or  specifications  such  as  design  and  product 
specifications  meet  the  users  original  needs. 

14  Perform  Consistency  and  Completeness  Analysis:  As 

errors  are  exposed  in  previous  activities,  tne  system 
description  is  refined  by  repeating  BLOCKS  3-13  until  a 
complete  and  consistent  system  definition  nas  been 
achieved. 

15  Manage  Requirements  Engineering  Activities:  During  each 
of  the  preceding  activities,  project  and  technical 
managers  determine  progress  by  the  analysis  team  and 
the  status  of  the  requirements  data  base. 
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in  tne  iol  lowing  paragraphs  each  block  in  Figure  /  lc  explained 
In  greater  detail.  Included  in  tne  description  are  the  PSL/PSA 
tool  features  whlcn  have  been  selected  as  a  subset  ol  tne 
language  and  analyzer  capabilities  best  suited  to  tne 
requirements  engineering  procedures  in  this  guidebook.  Alternate 
features  may  be  selected  based  on  tne  application  needs  ana  as 
experience  is  gained  in  application  ot  PSL/PSh. 


4.2  Identify  ana  Review  source  Docmentution  LbhuCk  1] 


Source  documentation  as  used  In  tnis  guidebook  includes  all 
recorded  information  on  a  system  such  as: 


o  planning  and  user  requirements  documents 

o  specifications  for  similar  systems,  tor  system 

interfaces,  and  for  existing  or  previously  defined 
subsystems 

o  documentation  derived  from  engineering  studies  and 
prototyping  or  experimental  test  systems 

o  user  interviews  and  associated  documentation 


During  tnis  task  tne  requirements  engineering  team  shall 
individually  review  the  source  documentation  in  order  to  become 
familiar  with  the  overall  system  requirements.  During  review 
sessions  with  other  team  engineers,  the  analysts  snail  perform  a 
general  evaluation  ot  the  requirement  types  (.objects}  contained 
in  the  source  documentation.  The  review  ot  the  source 
documentaton  and  the  assessment  of  requirement  types  are 
prerequisites  for  developing  the  requirements  engineering  plan 
[BLOCK  2J  .  As  tne  analysis  activities  [BLOCKS  J-14J  continues, 
additional  source  documents  will  be  identified  and  evaluated . 


4 .  J  Produce  Requirements  Engineering  Plan  IB LUCK  2J 


After  review  ot  tne  source  documentation,  the  analysis  team  snail 
determine  tne  specific  approach  to  accomplishing  BLOCKS  a-lb. 
Tnis  approach  shall  take  into  account  ali  available  resources 
including  personnel,  schedule,  and  financial  considerations.  The 
planning  snali  detail  tne  methodology  to  be  applied  (tools, 
techniques,  conventions,  etc.),  specific  tasks  to  be 
accomplished,  personnel  assignments,  resource  descriptions, 
scnedules  and  milestones,  preliminary  and  final  documentation  to 
be  produced  [BLOCK  12J ,  progress  reviews  and  quality  assurance 
and  status  reporting  procedures.  The  results  shall  be  described 
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in  a  requirements  engineering  plan  which  will  oe  updated 
throughout  tne  analysis  activities  to  retlect  necessary  changes, 
rne  requirements  engineering  plan  serves  to  define  tne  objectives 
and  means  of  the  analysis  to  be  performed  arid  assists  project 
start  in  performing  the  tasks  and  meeting  tne  goals  of  the 
project.  he*  analysts  and  otner  uniformed  observers  will  find 
tne  requirements  engineering  p.’an  useful  for  becoming  familar 
wltn  tne  requirements  engineering  project  throughout  tne 
project's  life. 

PbL/PSA  language  and  analyzer  features  snail  be  determined  oy 
review  of  oLOCKS  3-15,  Appendices  B  and  C,  and  tne  language  ana 
analyzer  references  in  Appendix  A.  mis  selection  snail  insure 
that  tne  analysis  proceeds  in  a  uniform  manner,  ana  the  PSL/PSA 
features  satisfy  tne  requirements  engineering  project  objectives, 
ine  objective  is  not  to  build  and  maintain  requirements  data 
bases  using  PS u/ PSA,  but  to  define,  analyze,  and  document  quality 
system  requirements  using  tne  oest  features  of  PSL/PSA  wnich 
satisfy  tne  analysis  activities  defined  in  tms  guide  boo*, 
inerefore,  PSL/PSA  shall  be  used  as  conservat lveiy  as  possible  to 
achieve  tne  objectives  of  the  project. 


4.4  identify  System  functions  (BLOCK  3J 


During  tnis  task  tne  source  documentation  is  analyzed  and  tne 
system  functions  C PROCESSES J ,  necessary  to  control  or  produce  tne 
desired  outputs  from  tne  available  Inputs,  snail  be  identified. 
A  function  is  a  discrete  activity  witnln  a  system.  The 
collection  of  discrete  functions,  defines  the  total  activities 
which  must  be  accomplished  by  the  system  to  achieve  a  given 
objective.  The  functions  identified  shall  range  from  high  level 
(first  possible  functional  breakout  of  the  system)  to  detailed 
lower  level  functions  (functional  primitives)  whicn  represent 
finite,  distinct  actions  to  be  performed  by  system  equipment, 
computer  programs,  personnel,  facilities,  procedural  data,  or 
combinations  thereof. 

Naming  a  function  is  an  important  part  of  tne  requirements 
engineering  process.  The  following  conventions  tor  developing 
function  names  snail  be  applied: 


o  Each  function  shall  be  qiven  a  unique  name  conforming  to  the 
function  name  of  the  sources  or  its  characteristics. 

o  The  function  name  snail  be  succinct.  This  increases  the 
ability  ot  the  reader  to  retain  the  idea  being  expressed, 
especially  tor  large  or  complex  systems  consisting  of  many 
functions . 
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o  lne  tunction  name  snail  not  imply  any  preterence  tor  d 
aeslgn  solution,  even  It  the  source  of  tne  requirement 
specifies  some  aspect  of  design. 

o  When  a  function  name  exceeds  30  characters.  It  can  be 
reduced  oy  aboreviatinq  parts  of  the  name,  Elnce  tne  tool 
does  not  nave  a  means  of  rer  rolng  abbreviations  used  in  a 
name,  a  separate  glossary  .  ;st  be  maintained.  Every  attempt 
snail  be  made  to  avoid  abbreviations,  since  they  decrease  tne 
readability  of  the  name  especially  tor  those  unfamiliar  with 
tne  abbreviations  employed.  The  need  to  abbreviate  is  often  a 
sign  of  an  ill-defined  requirement  or  a  combination  of 
requirement  types  and/or  modifiers. 

o  functions  wnlch  are  primitives  shall  include  a  PROCEDURE 
statement.  PROCEDURE  statements  shall  include  any  combination 
of  tne  following:  (1)  Structured  English  stating  tne  logical 
steps  which  represent  the  function,  (2)  Decision  Tables,  or 
131  Decision  Trees  [15J,  L19J. 

o  function  names  shall  conform  to  tne  following  constructs: 


CONSTRUCT  EXAMPLE 

Verb-Ob ject*  assemble -requisition 

asem-requisitlon- tor-publisher 

Compound-Verb-Object*  prepare-and-distr lb-reports 


*  with  or  without  modifiers,  such  as  adjectives  and/or 
preprepositlonal  pnrases. 


4.5  Organize  Functions  into  a  Hierarchical  Structure  16LQCK  4] 


In  conjunction  with  identifying  the  system  functions  as  described 
in  block  3,  tne  functions  snail  be  arranged  into  logical 
hierarchical  structures  (figure  2).  This  form  of  organization  is 
suited  for  structuring  system  functional  requirements  in  a 
logical  arrangement  for  communicating  system  functions  and  tne 
hierarch  leal  relationships  between  the  functions  to  design 
engineers.  The  functional  hierarchy  provides  a  view  of  the 
system  as  an  aggregate  of  functions  broken  down  into  a  logical 
arrangement  of  subordinate  discrete  activities  which  must  be 
performed.  The  sum  of  the  activities  of  the  functions  on  a  given 
level  are  equal  to  the  activity  at  the  next  higher  level  in  the 
hierarchy.  This  principle  means  the  total  system  activities  are 
defined  by  the  functions  at  the  lowest  level  in  tne  hierarchy 
(functional  primitives}.  Tnls  logical  form  of  organization  is 
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cl  1 s  t  t  ri'ju  i  siieti  1 1  o»i  Inf  01  -imI  i  im-i  Jon:.  li*Lu(>  '( J  •  i  r»rl  con  t  r  <>  1  - 1  1  o  * 
[BLOCK  10  J  . 

Trie  functions  ot  tne  system  snail  oe  grouped  Into  rugger  levels 
ot  organization  representing  the  first  possloie  Drea<out  of  the 
system.  Upper-level  functions  shall  oe  refined  by  tne 
identification  of  subordinate  levels.  Eacn  level  of  the 
hierarchy  shall  oe  limited  to  2-7  functions.  The  limit  of  seven 
functions  nas  been  shown  to  increase  tne  human  understanding  of 
the  system  functional  requirements.  Snould  tne  need  exist  for 
more  than  seven  functions  at  a  given  level,  the  analysis  team 
snail  review  upper  levels  of  the  hierarchical  structure  and  na*e 
any  adjustments  that  can  be  maae  to  resolve  the  prooiem. 

During  the  course  of  tne  organization  of  functions  into  a  logical 
nierarchy,  tne  names  of  previously  defined  functions  may  be 
altered  in  oroer  to  conform  to  the  logical  structuring  at  lower 
levels.  On  the  other  hand,  the  logical  structuring  may 
necessitate  the  creation  of  pseudo-function  names  in  order  to 
proviae  a  means  of  organizing  functions  unaer  special  ana 
meaningful  groupings.  In  addition,  the  hierarchical  structuring 
may  necessitate  identification  or  creation  or  new  functions  which 
were  omitted  during  previous  analysis. 

if  tne  functional  hierarchy  is  derived  from  leveled  data-flow 
diagrams  [BLOCK  «],  the  functional  hierarchy  can  be  aerivea  as  a 
result  of  the  hierarchy  of  parent-child  relationships.  This 
method  is  preferred  over  other  less  structured  means  ot 
functional  decomposition,  because  it  provides  a  balance  between 
the  decomposition  of  functions  In  parallel  with  the  decomposition 
of  data  flow  and  data  structure. 

The  language  statement  which  allows  a  function  (PROCESS)  to  be 
hierarchically  related  to  another  is  the  PART/SUBPART 
relationship  within  the  PROCESS  section.  The  reports  wnich  best 
shows  the  functional  hierarchy  is  the  Structure  Report.  Other 
reports  display  only  Immediate  PART/SUBPART  relationships: 
Picture  Report  (with  the  structure  option  in  effect)  and  the 
Formatted  Problem  ’ Statement  Report. 


4.6  identify  System  Constraints  [BLOCK  5) 


In  conjunction  with  the  identification  of  system  functions  and 
organizing  functions  into  a  hierarchical  structure,  the  analysis 
team  shall  identify  all  system  constraints.  The  constraint 
requirements  shall  be  limited  to  performance,  physical, 
operability,  and  design.  Test  requirements  are  addressed  in 
block  ll.  Constraint  requirements  shall  be  derived  from 
available  source  documentation  or  from  tne  results  of  trade-off 
studies,  feasibilty  studies  or  advanced  development  studies. 
Each  constraint  requirement  shall  be  related  to  specific  function 
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Levels  in  the  tunction.il  nierarcny  LBLUCr\  4J  .  A  constraint 
■tpplii'u  to  a  given  level  in  tne  functional  filer nrcny  Implies  thdt 
tne  constraint  Is  applicable  to  each  lower  level  function  in  tne 
hierarchy.  As  the  constraint  analysis  continues  the  constraints 
may  be  more  specifically  allocated  to  lower  level  functions  In 
tne  functional  hierarcny.  Constraints  which  are  not  clearly 
justified  from  available  ctocu  •‘ntation  shall  be  eliminated  from 
cons l oe rat  Ion  until  documented  justification  is  available.  All 
constraint  requirements  snail  be  stated  in  specific,  quantifiable 
parameters,  either  as  a  single  value  or  range  of  values. 
Including  the  unit  of  measure,  limits,  accuracy  or  precision,  and 
frequency . 

During  the  course  of  identifying  tne  various  constraints  imposed 
on  tne  functions  of  tne  system,  the  analysis  team  shall  verify 
tnat  no  combination  ot  constraints  results  In'  excessive  or 
unrealistic  requirements  [BLOCK  14]  .  Technical  risks  Identified 
by  the  analysis  of  constraints  snail  be  followed  up  Dy  additional 
studies  to  resolve  areas  of  conflict.  References  to  any  source 
documentation  or  analysis  and  studies  which  support  and  justify 
eacn  constraint  requirement  shall  be  maintained  using  SOURCES 
L  B  LOCK  13]. 

Although  some  methodologies  tor  requirements  engineering 
empnaslze  deferring  tne  laenti f ication  of  constraints  over 
preference  for  data-flow  analysis  tBLOCK  8],  It  is  better  to 
maintain  records  ot  the  constraints  as  they  are  identified.  This 
allows  the  analyst  a  means  of  deferring  the  constraints  in  a  way 
*hlcn  assures  that  each  one  will  not  be  lost  or  forgotten  ana 
also  provides  tne  oasis  from  which  constraint  analysis  may 
proceed. 

There  are  several  means  of  Identifying  constraints  using  the 
language.  One  way  is  to  use  the  ATTRIBUTE  and  ATTRIBUTE-VALUE 
statements.  For  example,  the  following  statement  shows  a 
performance  (pf-)  constraint  associated  with  the  function 
" validat e-time-car ds"  . 


PROCESS  validate-time-cards; 

ATTRIBUTES  ARE  p£-l-time-per-weeK  performance-constraint; 


tne  meaning  of  the  ATTKlaUTt  can  be  expanded  tnrougn  tne  use  ot 
tne  bhoCl  1  Pi  ION  statement  and  SOURCE  statement  In  the  ATTRIBUTE 
section.  description  allows  elaboration  on  tne  meaning  ot  the 
constraint  U.e.,  p  t  - 1  - 1  lme-per -week )  oy  allowing  text 
(comment-entries)  to  be  entered.  SOURCE  provides  the  means  ot 
identifying  the  source  ot  the  constraint  requi r ement  (analysis, 
studies,  reports,  etc.)  and  therefore  provides  for  traceability 
[BLOCK  1 3 j .  To  expand  tne  example,  the  following  DESCRIPTION  and 
SOURCE  statements  could  oe  provided: 
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PROCESS  vaiidate-time-cards? 

ATTRIBUTES  ARE  pf-l-tlme-per-weeic  performance -constraint? 

define  pf-i-time-per-weex  attribute? 

DESCRIPTION? 


comment-entry 


SOUkCE  source-identifier? 


In  tnis  example  the  first  two  statements  define  the  function  and 
the  associated  constraint.  Tne  remaining  statements  expand  upon 
the  constraint  by  renaming  it  and  adding  descriptive  text  and  the 
source  of  the  constraint.  Tne  use  of  the  prefix  (pf-)  for 
performance  in  the  ATTRIBUTE  name  appears  to  be  redundant  with 
the  ATTRIBUTE-VALUE.  However,  the  use  of  the  prefix  tnatces  other 
reports  more  useful,  since  many  of  the  reports  are  sorted  on 
object  names.  For  example,  the  Name  List  Report  will  group  all 
performance  constraints  together  where  the  prefix  " pf -M  is  used 
in  tne  ATTRIBUTE  name. 


The  ATTRIBUTE  and  ATTR IBUTE- VALUE  can  be  used  for  otner  contralnt 
types.  Prefixes  for  all  constraints  are  as  follows: 


performance 

Pf- 

Physical 

py- 

design 

dn- 

operability 

op- 

The  Attribute  Report  and  Formatted  Problem  Statement  Report  will 
display  the  constraints  (ATTRIBUTES)  along  with  tne  functions 
(PROCESSES)  which  they  contraln. 

Another  way  to  express  constraints  is  the  use  of  memos.  Using 
tne  same  example,  the  following  illustrates  tne  application  of 
MEMO  as  a  constraint: 


PROCESS  vali date-time- card? 
SEE- MEMO  pt-l-time-per-weeK? 

MEMO  pf-l-tlme-per-weex? 
DESCRIPTION? 


comment  entry 


SOURCE  source-identifier  (s) ; 
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Tfu*  1'tSCRU‘i  Llw  cirifi  .>  u  U  RCt.  statements  tor  trio  Mh;-’U  achieve  t -i<* 
same  results  us  the  AJ.  TRIBUTE'S  section.  here  tne  prefix  s 
distinguish  tne  ■■"h HU  ds  a  constraint  and  again  ere  useful  tor 
tu  oaucinq  ana  uslno  otner  report  outputs.  The  structure  Report, 
(j.^xi  ana  formatted  Problem  Statement  Report  will  display  tne 
constraints  ( memos  )  along  with  the  functions  ( RKUCESSES )  wnicn 
they  constrain. 

Anotner  means  for  defining  performance  constraints  which  Involves 
races  is  to  use  the  happens  statement.  Tne  Happens  statement 
specifies  the  nunoer  of  occurrences  of  a  function  (PHUCESS)  in  a 
given  time  interval.  The  following  statements  illustrate  tne 
happens  statement  to  express  tne  previous  performance  constraint: 


PROCESS  validate-time-caro; 
happens  one  times-per  week; 


ine  frequency  Report  and  Formattea  Problem  statement  Report  can 
oe  used  to  display  this  form  oi  performance  constraint.  otner 
contraint  types  C-py,  -op,  -dn)  nave  to  be  represented  using 
ATTRIBUTES  or  MEMOS. 


4./  identity  System  using  Activities  [3L0CK  si 


Using  activities  (organizations,  operational  units,  or  operator 
positions)  which"  interact  with  the  tarqet  system  shall  be 
identified.  The  identification  of  using  acitivlties  provides  tne 
oasis  of  information-flow  analysis  [BLOCK  B]  .  The  Identification 
shall  include  tne  names  of  using  organizations  described  in  the 
sources  or  through  other  determinations  such  as  human  engineering 
studies  whlcn  lead  to  tne  identification  of  using  activities. 
Lower  level  position  names,  such  as  specific  operator  positions, 
snail  be  identified  and  described  to  tne  level  of  detail  required 
for  the  associated  functions. 

Using  tne  INTERFACE  object  and  PARl'/SUBPART  statements,  the 
requirements  engineer  can  define  and  structure  all  using 
activities  which  interact  witn  tne  target  system.  l dent ificat ion 
of  using  activities  is  best  accomc  l  ishe J  in  conjunction  with 
inrormaLion-fiow  analysis  IBLUCin  BJ.  As  InIEKFACES  are 
identified  (i.e.,  external  activities  whlcn  are  origins  or 
destinations  of  targer  system  products),  language  statements 
should  be  prepared.  Tne  hierarchical  structuring  of  INTERFACES 
using  the  PART/SUBPART  relationships  is  generally  not  required 
unless  this  Information  supports  the  understanding  of  tne  target 
system.  An  example  entry  tor  a  using  activity  is  as  follows: 
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INTERFACE 

PART 

KECEl VtS 

GENERATES 

SOURCE 


keypunch-operator; 
aata-processinq -department; 
Keypunch-forms; 
xeypunch-decx; 
source-identitier(s); 


Tne  structure  of  the  using  activities  (INTERFACES)  is  provided  by 
tne  Structure  Report  if  tne  PAR1/SUBPARX  relationships  have  been 
entered.  Tne  Formatted  Problem  Statement  Report,  Extended 
Picture  Report,  and  Picture  Report  display  INTERFACES  wi  tn 
varying  degrees  of  informational  value. 


Anotner  approacn  to  identifying  and  structuring  using  activities 
Is  to  treat  tnem  as  PROCESSES .  Tne  using  activity  is  defined  as 
a  Process  and  given  a  name  wnlch  is  in  tne  noun  form  (e.g. 
oa ta-pr oces s ing-depar tmen t ) .  Tne  hierarcny  of  using  actlvites 
can  be  maintained  using  PART/SUBPART  statements  under  the 
PROCESSES.'  In  this  case  one  major  brar.cn  ot  tne  process 
structure  can  be  dedicated  to  tne  using  activities  ana  anotner 
brancn  set  aside  for  tne  target  system  functions.  Tnis  approach 
still  allows  identification  of  using  activities  (although  not 
specifically  by  language  type,  INTERFACES) ,  allows  nlerarcnical 
structuring,  and  data  flow.  Data  flow  becomes  more  simplified 
wltn  tnis  approacn  because  without  the  use  of  INTERFACE,  the  use 
of  INPUTS  and  OUTPUTS  are  no  longer  practical.  Tne  only 
practical  collections  of’  data  remaining  are  SETS,  ENTITIES, 
Gruups/ele^ENTS.  This  restriction  is  not  considered  severe.  To 
beginning  users,  this  approach  has  been  found  to  simplify  tne 
application  wnlie  still  effectively  addressing  tne  needs  of  tne 
requirements  definition  and  analysis  process.  Tne  tool  allows 
the  user  to  alter  the  type  of  the  object  from  PROCESS  to 
INTERFACE  should  it  be  decided  at  a  later  date  that  it  is 
desirable  to  do  so.  However,  because  of  tne  uniquenesses  of  eacn 
language  object,  a  change  in  the  type  ot  one  object  can 
necessitate  other  changes  within  the  object  being  changed  as  well 
as  other  objects.  Therefore,  it  is  suggested  that  use  of  PROCESS 
as  a  using  activity  should  be  adhered  to  throughout  the  project 
once  it  is  decided  to  do  so. 


4 .  u  Identify  External  System  lnputs-outputs  [BLOCK.  /  J 


In  conjunction  with  identifying  tne  using  activities,  tne 
analysis  team  shall  identify  the  output  (responses)  required  from 
the  system.'  Output  information  consists  of  reports  needed  by 
using  activities  as  well  as  system  messages  necessary  for  tne 
operation,  maintenance,  and  control  of  tne  system.  Subsequent  to 
each  output  being  defined,  tne  associated  system  inputs  (stimuli) 
shail  be  identified.  Each  input  or  output  (I/O)  snail  be  given  a 
unique  name  conforming  to  tne  I/O  name  In  tne  sources  or  its 
characteristics .  Parts  of  an  input  or  output  shall  be  Identified 
and  named  as  the  requirements  engineering  process  continues 
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[bLuCK  V).  Heterenceb  to  source  documentation  (SUUKCESJ  whicn 
identify  the  need  tor  the  I/U  snail  De  maintained  IBLOCK  UJ. 
Each  1/0  snail  be  suplemented  Dy  a  brief  description  of  tne  I/O 
and  Its  purpose. 

The  INPUT  and  OUTPUT  language  objects  are  designed  to  oe  used  as 
their  names  imoly,  that  is,  external  Inputs  and  outputs  of  tne 
target  system.  Tnese  collections  of  information  can  be  used  to 
express  physical  or  logical  collections  of  data.  As  pnyslcal 
collections  they  are  thought  of  as  containers  of  oata  values 
Which  consist  of  GROUPS/ELEMENTS .  INPUTS  ana  OUTPUTS  may  also  be 
contained  in  larger  collections  of  information,  inputs,  OUTPUTS, 
and  SETS.  For  requirements  engineering  purposes,  the  logical 
collections  are  the  preferred  means  of  usinq  tne  language. 

Example  INPUT  and  OUTPUT  statements  are  as  follows: 


INPUT  time-card; 

GENERATED  BY  keypunch-operator; 

description; 


comment  entry 


SOURCE  source-identlfierCsl; 

OUTPUT  keypunch-forms; 

RECEIVED  BY  keypuncn-operator ; 
description; 


comment  entry 


SOURCE  source-identlf ier  ( s  ) ; 


1.9  Perform  Information-Flow  Analysis  l BLOCK  8J 


During  this  analysis,  tne  flow  relationships  between  external 
system  inputs  and  resulting  outputs  shall  be  identified  in 
Intormatlon-rlov  diagrams  (also  called  data  flow  diagrams  and 
data  flow  grapnsj.  These  diagrams  provide  tne  Dasis  tor 
determining  tnat  each  I/o  is  used,  derived,  or  updated.  An 
effective  means  of  information-flow  analysis  is  to  trace  an 
output  back  to  the  system  input:  external  data,  messages,  or 
stimuli.  This  method  permits  the  reiationsnl ds  between 
associated  functions  and  tne  internal  information  necessary  to 
support  the  derivation  of  tne  output  to  be  laentified. 
Structured  approacnes  for  Information-flow  analysis  are  described 
by  DeMarco  lldJ,  Gane  and  sarson  1 1 9 J ,  and  Ross  ll4J.  The  data 
flow  within  the  target  system  boundary  can  be  described  using  the 
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following  ionauag  e  r  e  1  a t  lonsh  t  r>u  os  illustrated  In  t  lyure  B: 


U;jEs  tms  relationship  indicates  tn  it  o  tunction  (PROCESS) 

on  the  path  uses  external  information  (INPUT*)  or 
internal  system  Information  (EMIT!*)  as  an  Input 
to  Its  activities. 

DERIVES  IMS  relationsnlo  indicates  tnat  a  function  (PROCESS ) 
on  the  path  derives  either  external  information 

(OUTPUT*)  or  Internal  system  information  (EMIT**)  as 
a  product  of  its  activities. 

UPDATES  Tnls  relationship  indicates  that  a  function  (PROCESS) 
on  tne  pdtn  updates  internal  system  information 

(ENTITY*)  as  part  of  its  activities. 


*  or  tnelr  higher/lower  level  collections,  i.e.,  SETS, 
GROUPS/ELEMENTS 


Compound  forms  can  also  be  used  such  as  USES-  TO  DERIVE  and  USES- 
TU  UPDATE.  These  forms  are  better  since  they  result  in  a  more 
accurate  definition  of  the  function's  transaction  and  result  in 
more  ‘meaningful  PSA  reports,  i.e..  Picture  ana  Extended  Picture 
reports. 

Tne  information  flow  shall  indicate  the  relationship  between 
system  functions  and  system  Information  (external  ana  internal 
system  I/O)  and  shall  not  Imply  any  lapse  in  ‘  time,  or 
intermediate  1/0  be  used,  derived,  or  updated. 

For  the  purpose  of  information-flow  analysis  tne  external  using 
activities  Identified  during  BLOCK  b  are  integral  to  the 
definition  of  the  system  total  Information  flow  since  the  using 
activities  are  the  origins  and  destinations  or  system  external 
i/o.  The  flow  across  tne  target  system  boundary  (between 
INTERFACES  and  PROCESSES,  If  INTERFACES  are  being  used  to 
represent  using  activities)  shall  be  described  using  the 
following  information-flow  relationships  as  illustrated  in  Figure 
B: 


GENERATES  Tnls  relationship  indicates  (1)  a  using  activity 
(INTERFACE)  is  tne  origin  of  tne  external  Input 
(INPUT)  or  (2)  a  function  (PROCESS)  Is  the  origin 
of  tne  external  output  (OUTPUT). 

RECEIVES  This  relationship  indicates  (1)  a  function 
(PROCESS)  is  the  recipient  of  the'external  input 
(INPUT)  or  (2)  a  using  activity  (INTERFACE)  is  the 
recipient  of  tne  externai  output  (OUTPUT). 
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Figure  8.  Information-Flow  Diagram  with  PSL  constructs 
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Two  possible  sets  ot  language  statements  wnlcn.  corresponds  to  tne 
information-flow  diagram  In  figure  b  are  shown  below.  Each  set 
ot  statements  should  be  supplemented  by  a  SOURCE  statement  where 
it  is  appropriate  to  maintain  traceability  between  the  flo» 
requirement  and  sources  of  the  requirement  [BLOCK  ldj. 


SIMPLEX  FORM 

COMPUUND  FORM 

INTERFACE  a; 

INTERFACE  a; 

GENERATES  b? 

GENERATES  b; 

INPUT  b? 

USED  BY  c; 

INPUT  b; 

PROCESS  c; 

PROCESS  c; 

RECEIVES  b; 

RECEIVES  b; 

USES  D  TU  DERIVE 

e; 

DERIVES  e; 

ENTITY  e; 

PROCESS  f; 

ENTITY  e; 

USES  e  TU  DERIVE 

h; 

USED  BY  f; 

USES  e  TU  UPDATE 
GENERATES  h; 

9? 

PROCESS  f; 

UPDATES  g; 

output  n; 

DERIVES  h; 

GENERATES  h; 

INTERFACE  1; 
RECEIVES  n; 

OUTPUT  h; 
RECEIVED  BY  i; 


INTERFACE  i; 


Reports  which  present  the  information  flow  are  the  Data  Process 
or  Data  Process  Interaction  Report,  Element  Process  Analysis 
Report  and  Element  Process  Usage  Report,  Extended  Picture  Report, 
Formatted  Problem  Statement  Report,  Function  Flow  Data  Diagram 
Report,  Picture  Report,  Process  Input/Uutput  or  Process  Summary 
Report,  and  the  Structure  Report.  None  of  these  reports  present 
leveled  aata  flows. 


4.10  Structure  System  Information  [BLOCK  yj 


During  BLOCK  7,  the  external  I/O  C  INPUTS,  OUTPUTS;  and  their 
superordinate  and  subordinate  parts  are  defined.  During  BLOCK  b, 
the  internal  I/u  (ENTITIES;  and  their  superordinate  and 
subordinate  parts  are  defined  as  the  information-flow  analysis  Is 
performed.  During  this  activity,  the  external  and  internal 
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information  is  arranged  into  logical  nierarcnical  structures 
Ldata  structures)  as  illustrated  in  Figure  i.  '  The  emphasis  on 
the  data  structures  is  to  organize  the  i/O  and  their 
s uperordinate  and  subordinate  parts  into  logical  organizations  or 
simply  as'  groupings  of  information.  Structuring  tne  I/O  is  an 
effective  means  of  identifying  incomplete  or  missing  i/O  and  for 
communicating  the  input  and  output  requirements  to  design 
engineers. 

parts  of  I/O  Identified  during  BLOCK  7  and  a  shaii  oe  associated 
with  other  I/O  and  organized  into  hierarchical  structures. 
Changes  and  additions  to  tne  I/O  hierarchical  structures  may  be 
required  as  information-flow  analysis  LB LOCK  b)  is  accomplished. 
Tne  upper  parts  of  the  individual  I/O  hierarcnlcal  structures 
shall  be  equivalent  to  tne  aggregate  of  the  subordinate  parts  in 
the  nierarcny.  During  tne  course  of  organizing  the  i/O  into  a 
hierarchy,  the  names  of  previously  defined  I/O  may  be  altered  In 
order  to  conform  to  tne  data  structure  being  defined.  On  the 
other  hand,  tne  structuring  may  necessitate  tne  creation  of 
pseudo  Input/output  names  in  order  tc  provide  an  effective  means 
of  organizing  tne  data  structures  in  special  and  meaningful 
groupings.  In  addition,  the  hierarchical  structuring  may 
necessitate  the  Identification  of  additional  I/O  requirements 
which  were  omitted  during  earlier  requirements  engineering 
activities . 

The  identification  of  the*l/0,  its  description,  structure,  and 
otner  features  is  called  a  data  dictionary.  The  following 
example  describes  a  typical  data  dictionary  entry  tor  an  INPUT, 
fcacn  set  of  statements  can  be  supplemented  by  a  SOURCE  statement 
wnere  traceability  is  desired  or  required  [BLOCK  1JJ . 


INPUT  time-card; 

CONSIST  OF  employee-name,  employee-no,  week-ending-date , 
project-numbers,  mon-nrs,  tue-nrs,  wed-hrs, 
thr-hrs,  fri-nrs,  sat-hrs,  sun-hrs, 
total-hrs -by-project-no,  totai-hrs-by-week-day; 

DESCRIPTION; 

A  card  used  by  tne  employee  to  record  weekly  hours 
against  projects  throughout  the  work  week; 

SYNONYM  employee-time-card; 

GROUP  employee-name; 

CONSISTS  OF  last-name,  first-name,  middle-initial; 

ELEMENT  last-name,  first-name,  middle-initial; 


Several  reports  will  present  various  aspects  ot  the  data 
dictionary.  The  Contents  Report  provides  the  data  structure  in 
an  indented  format  beginning  with  the  ooject  name  specified  (SET, 
Input,  output,  entity)  down  to  the  lowest  levei  defined  using  tne 
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cons ists/Containeo  statements.  The  structure  Report  eversion 
S.i,  with  the  appropriate  options  in  effect)  provides  an  indented 
hierarchy  of  tne  SETS,  INPUTS,  OUTPUTS,  and  ENTITIES  based  on  the 
PART/SUBPART  and  SUBSET/SUBSETS  relationships.  The  Formatted 
problem  Statement  Report  provides  the  same  data  structure 
(CUMSISTS/CONTAINED)  information  as  well  as'  DESCRIPTIONS, 
SYnunKMS,  and  SOURCES.  Other  reports  which  aid  in  development 
and  analysis  of  data  structure  and  contents  are  identified  in 
Appendix  C. 


4.11  Perform  Control-Flow  Analysis  IBLOCK  10) 


Controi-flow  analysis  provides  a  means  of  viewing  tne  system  from 
an  activity-oriented  perspective  and  is  often  referred  to  as 
functional-flow  analysis.  Control-flow  diagrams  like  Figure  9 
describe  the  sequential  flow  between  system  functions.  Whereas 
the  information  flows  do  not  indicate  any  preferred  ordering  of 
functions,'  control  flows  describe  the  order  in  which  functions 
are  to  be  actlviated.  in  many  applications  these  control  patr.s 
become  meaningful  in  the  understanding  of  the  system  and  are 
desired  by’ the  target  system  user  or  documentation  requirements, 
wnere  control- flow  analysis  is  desired  or  required,  it  is 
recommended  that  the  ordering  of  functions  be  prepared  after 
completion  of  information-flow  analysis. 

Control-flow  diagrams,  like  information-flow  diagrams,  shall 
indicate  only  the  relationship  between  system  functions  and  shall 
not  imply  any  lapse  in  time,  or  intermediate  activity.  The 
sequence  of  functions  (PROCESSES)  and  conditions  which  determine 
the  flow  directions  shall  be  described  using  the  following 
control-flow  relationships  as  Illustrated  in  Figure  9: 


TRIGGERS  This  is  a  sequential  relationship  between  two  or 

more  functions  (PROCESSES). 

UTILIZES  This  relationship  Indicates  that  a  function 

(PROCESS)  on  a  path  Is  dependent  upon  the  use  of 
one  or  more  other  functions  in  order  to  accomplish 
its  activities.  A  single  function  or  sequence 
of  functions  may  be  defined  once  and  utilized 
as  frequently  as  necessary  in  the  control  flow 
without  having  to  be  redefined  for  each  use. 

CONDITION  AND  condition:  Functions  (PROCESSES)  preceding 

tne  AND  must’  be  accomplished  Detore  tne  flow 
can  continue. 

OK  condition:  Any  one  of  the  alternate  paths  may 

lead  to  the  next  function  (PROCESS). 


UTILIZES:  B  utilizes  C 

C  utilized  by  B 
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Figure  9.  Contra-Flow  Diagram  with  PSL  constructs 
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lne  use  oi  tne  TRIGGERS  and  UTILIZES  r eiationsmps  provides  tne 
basic  sequence  of  functions  (functional  flow).  Tne  addition  of 
Conditions  statements  modifies  the  functional  flow  oy  providing 
control  descriptions  on  diverging  or  converging  flow  paths  and 
thereby  makes  the  sequence  of  functions  a  control  flow. 

The  control  flow  snail  be  restricted  to  concepts  backed  by  system 
engineering  studies  or  the  like  which  clearly  resolve  any 
uncertainty  of  technical  risks  associated  with  the  flow  concept 
described.  where  uncertainty  exists  tne  relationships  snail  be 
described  as  tentative  or  not  completed,  as  appropriate,  until 
subsequent  analysis  resolves  the  uncertainty.  As  the  control 
flow  is  identified,  SOURCES  of  the  control  requirements  (studies, 
reports,  etc.)  shall  be  maintained  (BLOCK  13). 

One  possible  set  of  language  statements  which  corresponds  to  the 
control-flow  diagram  in  Figure  9  is  shown  Delo*.  Each  set  of 
statements  should  be  supplemented  by  a  SOURCE  statement  wnere  it 
is  appropriate  to  maintain  traceability  between  the  flow 
requirement  and  sources  of  tne  requirements  (BLOCK  lJJ. 


PROCESS  a? 
TRIGGERS  b; 

PROCESS  d; 
UTILIZES  c; 
TRIGGERS  d; 

PRUCESS  d; 
TRIGGERS  e, f ; 

PROCESS  g? 
TRIGGERED  BT  e,f; 


TRIGGERED 
TRIGGERS  h 

WHEN 

condition-name 

BECOMES 

TRUE; 

PROCESS  h; 

TRIGGERED 
TRIGGERS  j 

WHEN 

• 

/ 

condition-name 

BECOMES 

TRUE? 

PROCESS  i; 

TRIGGERED 
TRIGGERS  j 

WHEN 

• 

9 

condition-name 

BECOMES 

FALSE 

In  the  above  example,  "condition-name"  is  the  object  name 
(maximum  of  30  characters)  called  a  condition  (AND  condition,  and 
OR  condition).  The  condition-name  is  a  '  statement  which 
represents  a  condition  which  can  be  either  in  a  true  or  false 
state,  once  the  condition-name  is  determined,  tne  TRUE  or  FALSE 
Is  selected  as  appropriate  to  tne  logic  of  the  flow  being 
defined. 
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Si’verai  reports  display  control-flow  Intormdt ion.  'lne  process 
Chain  Report  provides  a  grapnic  output  snownlny  tne  cnaln  o t 
TRIGGERS,  UTILIZES  (S.l  only),  ana  CONDITIONS  (S.l  only).  Ail 
control-flow  relationships  are  shown  In  the ‘Formatted  Problem 
statement  Report  and  also  In  the  Structure  Report  (3.2X  only). 
The  Dynamic  Interaction  Report  (S.l  only).  Picture,  and 
utilization  Analysis  Report  (s.l  only) ‘also  show  various  aspects 
of  control  flow. 


4.12  Perform  Test  Analysis  (BLOCK  11) 


Test  requirements  identify  tne  system  requirements  wnicn  will  De 
evaluated  during  system  integration  and  . test.  Tne  principle 
objective  of  test  analysis  is  to  identity  wnicn  areas  in  the 
system  definition  shall  underqo  formal  test  and  ver ificat i on . 
Tnis  is  achieved  by  identifying  test  points  on  the  control-flow 
patns  (figure  9).  Test  points  snail  ue  added  to  tne  flow  patns 
at  the  selected  test  data  sampling  iocations  as  the  control  flow 
is  developed.  Tne  selection  of  test  points  snail  be  accomplished 
concurrent  with  the  test  planning  activities. 

Tne  association  between  system  test  plans,  analyses,  and  studies 
documented  prior  to,  auring,  and  subsequent  to  tne  start  of 
formal  requirements  engineering  is  crucial  to  tne  overall 
requirements  engineering  concept.  Documented  test  objectives 
preceding  formal  requirements  engineering  shall  be  analyzed.  As 
a  result,  test  points  in  the  control  flows  shall  De  selected 
which  provide  data  for  various  test  cases  and  support  testing 
objectives.  References  (SOURCES)  shall  be  maintained  between  the 
test  points  and  associated  test  plans  and  other  supporting 
documentation  (BLOCK  13). 

The  language  has  no  direct  means  of  representing  test  points  on 
tne  information  and  control  flows.  However,  one  means  of 
representing  these  test  points  can  be  achieved  tnrough  the  use  of 
tne  EVENT  object.  In  this  case’ the  EVENT  denotes  a  point  on  the 
flow  where  test  (validation)  data  is  desired  during  the  system 
testing.  Tne  procedures  which  will  be  used  to  analyze  the 
collected  data  can  be  described  m  the  DESCRIPTION.  References 
(SOURCES)  to  test  plans  and  procedures  can  be  Identified.  A 
single  test  case  may  be  defined  as  an  EVENT  made  up  of  several 
test  points  (EVENTS)  using  PART/SUriPARX  relationships .  All  test 
cases  can  be  structured  to  provide  a  comprehensive  hierarchy  of 
the  system/subsystem  and  unit  level  testing  whicn  will  be 
performed  during  system  integration  and  test.  lne  following 
statements  illustrate  a  test  case  for  the  control  flow  shown  in 
f lgure  9: 


EVENT  test-case-name; 

SUBPARTS  ARE  tes t-point-a ,  test-polnt-b; 
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description; 

comment  entries  describing  tne  procedures  tor 
analyzing  the  test  point  data.  This  may  be 
extracted  from  or  entered  into  test  plans  and 
procedures  as  they  are  developed; 
source  source-identif ier ( s  1 ; 


event  test-point -a; 

CAUSED  BK  a; 

TRIGGERS  b; 

description; 

comment  entries  describing  tne  test  data  to  be 
collected; 

SOURCE  source-identifier ( s  ) ; 


event  test-point-b; 
caused  by  h,l? 

TRIGGERS  3; 

description; 

comment  entries  describing  tne  test  data  to  be 
collected; 

SOURCE  source-identlf ier (s) ; 


The  PART/SUBPART  r elationships  are  available  only  in  version  5.1. 

Tne  test  cases  and  test  points  (EVENTS!  will  appear  in  numerous 
reports  depending  on  the  version  available.  The  Structure  Report 
(5.11  will  display  the  hierarchy  of  the  test  cases/points  based 
on  the  PART/SU8PAHT  relationships  (5.11.  The  Process  Chain 
Report  (all  versions!  and  the  Dynamic  interaction  Report  (5.11 
will  display  the  test  points  (EVENTS!  as  part  of  the 
functional/control  flow.  The  Formatted  Problem  Statement  Report 
generated  for  EVENTS  will  provide  a  complete  display  of  the  test 
cases/points.  The  lack  of  PART/SUBPART  Relationships  in  ersion 
3.2  and  4.2  can  be  worked  around  by  the  analysis  team  using  an 
alphanumeric  naming  convention  for  the  test  case/points  (EVENT 
names!  wnlch  will  allow  reports  such  as  the ' Formatted  Problem 
Statement  Report  to  output  ordered  by  the  name  of  tne  EVENTS.  In 
this  case  the  Name-Gen  (3.21  or  Name-Selection  (4.2,  and  5.11  is 
used  to  create  a  file  of  EVENT  names  ordered alphabet lcally. 
men  tne  formatted  troolem  statement  Report  can  oe  produced.  me 
result  is  a  listing  of  the  test  cases/points  in  the  preferred 
order  based  on  the  name  of  the  event. 


4.13  Prepare  Specification  Documentat ion  [BLOCK  12J 


Specification  documents  serve  to  xecord  tne  requirements,  design, 
and  product  descriptions  of  a  system.  Specif lcatlons  are  used 
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ri.i(>v,,(ncut  trie  system  life  cycle  jre  an  Integral  part  o t  tne 
system  management  concept:  contracting  ana  development , 
com vgurat ion  management,  system  integration  and  testing, 
t a  in t enanc e ,  and  modi t tcatlons . 

Documentation  is  developen  according  to  aliterent  standards 
depending  on  the  type  of  system  peiny  deiineu.  wnere  tne  system 
requirements  are  tor  a  military  system  wnich  can  De  satisfied  by 
an  automated  data  processing  (  A  D  P )  configuration  of  computer 
njrmare  and  software,  tne  uoD  Standard  7935. 1-S,  Automated  Data 
systems  Document  at  ion  Standards,  is  usually  applied.  In  military 
systems  wnere  ADP  Hardware  ana  software  may  oe  part  of  a  larger 
system  ot  equipment,  sucn  as  a  weapons  system,  * il-S l'b-4 90 , 
Military  standaro  Specification  Practices,  may  oe  tne  requirea 
document  Ion  standard.  Altnougn  tne  formats  and  content 
requirements  ot  these  two  standards  vary,  each  can  araw  upon  the 
products  of  tne  analysis  performed  in  the  preceding  blocks . 

Tne  system  requirements  definition  and  analysis  activities 
looucns  3-ill  provide  the  basis  upon  wnich  tne  preparation  ot 
specification  snail  proceed.  Tne  products  of  BLOCKS  3-11 
(functional  and  informational  hierarchical  structures, 
information  ana  control  flows,'  etc.)  shall  be  incorporated 
directly  into  tne  specification  documents  in  accordance  with  the 
prescribed  format  of  the  documentation  standard  by  using  the 
analyzer  reports  as  figures  or  appendices  in  tne  specification 
documents.  Additional  sped f lcation  document  paragraph  headers 
and  text  may  be  required  to  complete  the  document  in  order  to 
explain  the  analyzer  reports  or  provide  continuity  between  the 
reports  ana  the  format  requirements  of  tne  standard.  Where 
additional  text  is  required  to  satisfy  the  documentation  standard 
format,  the  added  text  shall  be  direct  and  succinct.  The  text 
shall  be  free  of  vague  and  ambiguous  terms.  The  text  shall  use 
tne  simplest  words  and  phrases  wnich  convey  the  intended  meaning. 
Care  shall  be  taken  to  ensure  that  the  supplemental  text  does  not 
conflict  with  previously  defined  system  requirements  [BLOCKS 
3—113 .  Where  conflicts  arise,  tne  previous  requirements 
definitions  and  analysis  snail  take  precedence,  any  conflicts  in 
tne  supplemental  text  shall  be  removed. 

The  Intent  of  the  text  is  to  provide  supplemental  understanding 
of  tne  requirements  identified  and  analyzed  previously.  The 
style  ot  writing  shall  emphasize  short  ana  concise  sentence 
structure.  well-written  sentences  snail  be  required  witn  a 
minimum  of  punctuation.  Punctuation  shall  be  used  to  aid  reading 
and  prevent  mlsunder s tandlngs i  When  extensive  punctuation  is 
required  for  clarity,  the  sentence  shall  be  restructured  to 
eliminate  the  deficiency.  Tne  emphasis  shall  be  upon  short  and 
concise  sentences  and  the  elimination  of  compound  clauses. 
Additional  style,  format  and  general  instructions  for  preparation 
of  specification  documents  shall  be  accomplished  as  described  in 
Dob  Standard  7935. 1-S,  Part  2  ,  and  hil-std-490,  paragraph  3.2. 
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Only  a  te*  specltlcation  types  In  uou  standard  /VJb.l-S  and 
MIl.-5TD-4yo  are  used  to  record  tne  results  of  Uie  system  modeling 
daaressed  In  this  guidebook.  l'nese  are  as  follows: 


DoD  Standard  I 933.1-3 

Functional  Description  U-h) 

Data  Requirements  Document  Ci'O) 
System/SuDsystem  Specification  iss; 

Ml L“ STD- 4y  0 

System  Specification  (Type  A) 
Development  Specifications  (Type  B) 


Tne  formats  of  each  of  these  specification  types  are  uniquely 
different  and  do  not  easily  lend  tnemseives  to  tne  outputs  of  tne 
analyzer.  As  stated  previously,  tne  analyzer  reports  can  oe  used 
as  figures  or  as  appendices  to  support  the  paragraph  requirements 
of  the  documentation  standards.  where  these  documentation 
standards  are  not  required,  the  analyzer  outputs  identified  in 
the  previous  activities  [BLOCKS  3-11J  can  oe  used  as 
specifications  '  for  the  target  system.  However,  additional 
supporting  text  to  explain  tne  analyzer  reports  and  provide  a 
comprehensive  specification  of  the  system  will  oe'requlred.  The 
Print  Requirements  report  (3.2XJ  has  been  developed  to  provide 
automated  documentation  directly  from  the  requirements  data  base 
as  described  In  Appendix  C  and  as  illustrated  in  Appendix  D. 


4.14  Perform  Traceability  Analysis  [BLOCK  13J 


Traceability  gives  the  analyst  a  means  of  verifying  the 
requirements  by  linking  each  requirement  to  tne  varying  forms  of 
source  documentation  such  as  program  directives  and  plans, 
studies,  analyses,  test  plans,  associated  specifications  CFD,  RD, 
55  or  Type  A  and  b)  and  the  like.  Throughout  the  requirements 
engineering  activities  tne  need  exists  for  the  analyst  to  be  able 
to  evaluate  the  impact  of  chanyes  and  additions  to  the 
requirements  (Figures  ID  ana  llj.  Whatever  tne  reason  (policy, 
economics,  study  or  analysis  results,  engineering  cnange 
proposals,  etc.),  traceability  provides  the  capability  to  reaally 
Identify  associated  impacts  to  the  system  definition  as  well  as 
to  trace  the  impacts  to  all  other  associated  documentation. 
Requirement  change  impacts  can  oe  readily  analyzed  and  the 
appropriate  actions  taken  wnere  the  sources  and  traces  of 
requirements  are  identified.  The  links  to  associated  plans, 
analyses,  studies,  and  specifications  accomplished  prior  to, 
auring,  and  subsequent  to  the  start  of  formal  requirements 
engineering  are  crucial  to  tne  integrity  of  the  system  being 


LOGICON 


PACK  Ad 


t-tiiej  a  n  i  d  e  v  e  i  o  p  e  d  . 

mere  are  t  *■  o  forms  ot  traceability:  traces  trou  trie  originating 
regulrerrents  to  the  logical  model  and  traces  trom  the  logical 
moaei  to  other  models  wnere  the  requirements  nave  oeen  allocateu 
sucn  as  more  detailed  logical  models,  physical  designs  (design 
specifications),  and  as-ouilt  pronucts  (product  specifications), 
me  sUUPCfc.S  ana  IKACF-K LY  statements  are  employed  to  address  ootn 
fores  ot  t r aceaoi 1 1 1 y  .  • 

SbuKCfc  statements  are  used  curing  tne  logical  modeling  as 
descrloeo  in  BLOCKS  d-il  to  identity  tne  originating  source  ot 
tne  requirement  Connects:  PrsUCtSS,  INTtRi-ACe.,  Stl,  IdPU'i, 
OUTPUT,  lnTIIy,  GHOUP/t.Lt:Ht.N'i  etc.).  Inis  can  be  cone  oy  use  ot 
a  unique  SOURCE  name  (source-iaentitier).  mis  laentitier  is 
otten  the  page  and/or  oaragrapn  ot  a  source  document.  Tne  more 
specific  tne  identifier,  tne  easier  it  is  to  locate  the  source  ot 
tne  requirement,  especially  oy  individuals  who  were  not  involved 
In  tne  analysis.  wnere  multiple  source  documents  are  to  be 
referenced,  tne  sour ce-iaen t 1 t 1 er  snould  begin  witn  a  pretix 
(usually  one  cnaracter  is  sufficient)  to  alstinguisn  me  unique 
scarce.  For  example,  J-j.1.1.2  represents  paraqrapn  1.1.1. 2  In  a 
oocu  iient  identified  by  tne  project  analysts  as  "j"  , 

Traces  to  allocated  requirements  are  accomplished  using  tne 
1  k  ACfc-KL  i'  statement.  The  preferred  method  is  to  ads  TRACL-KLY 
statements  to  tne  PSO/Pba  data  base  of  the  logical  model  where 
the  requirement  Is  first  recoroea  (i.e.,  the  originating  model), 
tor  instance,  THACE-KEY  statements  would  be  addeu  to  the  logical 
model  (originating  model)  wnen  the  requirements  nave  been 
allocated  or  refined  (expanded  upon)  in  anotner  more  detail  model 
(allocated  model).  The  name  ot  trie  TRACE-KEY  (trace-identifier), 
1  Ik  e  the  source-identifier  for  SUURCES ,  can  be  to  tne  page  ana /or 
paragrapn  of  the  document  wnere  tne  requirement  was  allocated  or 
the  actual  name  ot  the  allocated  requirement  (object)  in  tne 
second  moaei  as  maintained  in  a  PSL/PSA  data  nase. 

Throughout  tne  requirements  engineering  activities  (BLOCKS  J - l 1 3 
each  requirement  shall  be  associated  with  tne  sources  of  the 
requirement  (source  documents).  'inese  SOUKCLS  shall  relate  tne 
system  requirements  to  all  associated  specifications,  studies, 
analyses,  plans,  program  management  directives  ana  plans,  system 
sizing  ana  timing  studies,  f  r  otntypi.v ,  simulations,  test 
planning,  ana  tne  lihe.  .SUUriCr.  Staten. eats  snail  re  lhcluaeo  tor 
eacn  requirement  type  (language  oojects)  as  appropriate  to  tne 
analysis.  The  source-ident 1 tei s  snould  be  specific  enough  tnat 
tne  requirement  can  oe  locateu  on  a  single  page  of  tne  source 
document.  TRACE-KEYS  shall  be  edged  to  the  originating  PSu/PSA 
data  base  when  the  re  quire  ments  in  the  originating  rrcnel  have 
been  allocated  to  more  detailed  models;  Inis  snail  be 
accompilsnea  even  if  tne  allocated  model  is  not  actually  defined 
in  a  P  S  L  /  P  S  A  data  base.  ini'  nano  ot  the  TKACb-rvEY  Should  ce 
el tner  tne  object  name  in  tne  allocated  moaei  (PROCESS, 
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tMt.ifUCt,  i>fc.T,  INPUT,  UdTPUT,  K  iM  ’I  I T  Y  ,  oHUUP/fLfc.rtfc.fc T  etc.)  or  the 
location  ot  the  requirement  in  the  allocated  mouei  (l.e., 
aocunent  page/paragrapn  numbers).  Since  the  allocated  model  may 
not  De  represented  In  a  psl/psa  data  case,  tne  page/paragrapn 
numbers  of  tne  requirements  in  the  allocated  document  are  otten 
tne  only  appropriate  TRACL-Kfc.Yo  that  can  De  added  to  tne 
originating  model.  The  lOilowinq  example  snows  tne 
identification  ot  SUUHC6.S  and  TRACE-KEYS  tor  a  PKUCtSS: 


PROCESS  va li date-time-card s; 

SOURCE  j-3. 1.1.2,  J-3. 1.1. 2.1; 

IhACd-kEY  n-3.7.1.2,  n-3.7 .1 .2. 1 .3  ,  t-4.J.S.3; 


in  tms  example  two  unique  reterences  (SOUKCtS)  have  Deen 
Identified  for  the  originating  requirement  and  tnree  references 
(.TRACfc.-Kc.YS)  have  beer  identified  as  the  location  of  tne 
requirements  in  two  other  documents  C  n-  and  t-).  The  SQUkCL' 
statements  indicate  that  the  function  (PROCESS) 
"vaiidate-tlme-car ds "  originated  In  document  and  is  discussed 
in' paragraphs  3 . 1.1. 2  and  J.  1.1. 2.1.  The  function  traces  to 
requirements  allocated  and  refined  In  two  otner  documents: 
document  ' n '  paragraphs  3. 7.1.2  and  3. 2. 1.2. 1.3  ana  document  't' 
paragrapn  4. 3. 5. 3. 

(Jnly  a  few  reports  display  SOURCES  and  TRACt-KKYS.  These  are  tne 
formatted  Proolem  Statement  Report,  Requirements  Traceaolltiy 
Analyzer  Report  13. 2X)  and  the  Structure  Report  C3.2X).  Tne 
Requirements  Traceability  Analyzer  Report  has  oeen  specifically 
designed  to  analyze  the  traceabilty  of  requirements  and  display 
tne  results  or  the  trace  Detween  two  PSL/PSA  data  Dases  in  a 
single  report. 


4.1b  Perform  Consistency  and  Completeness  Analysis  [BLOCK  14] 


Throughout  tne  requirements  engineering  activities  LBLOCKS  3-13) 
analysis  of  the  consistency  ana  completeness  of  the  requirements 
definition  assures  tne  integrity  of  tne  system  oeing  defined. 
The  analyzer  reports  assist  tne  requirements  engineer  in 
consistency  and  completeness  analysis  ny  li)  enforcing 
consistency  and  u  n  a  m  d  i  g  u  i  t  y  ny  cnecMng  tne  syntax  jf  tne 
requirements  statements  [2)  detecting  some  types  ot  logic  errors 
In  the  requirements  statements  and  [3]  aiding  tne  detection  ot 
incomplete  and  Inconsistent  requirements  statements.  hy  far  tne 
majority  of  inconsistencies  ana  1 nc omp  1  e t enes s e s  are  detected  d/ 
tne  requirements  engineer  as  opposed  to  tne  analyzer.  inis  is 
done  py  observation  of  tne  analyzer  reports  as  tne  engineer 
necomes  highly  associated  with  the  problem  that  Is  neinq  modeled. 
Various  reports  nave  ouilt-in  analysis  features  which  detail 
certain  classes  ot  syntax  or  logic  errors. 
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In  usinq  trie  reports  identi.tl.ea  in  tne  previous  BLOCKS  ana  other 
reports  wni.cn  may  De  employed  as  describee  in  Appendix  C,  the 
following  minimum  consistency  and  completeness  cnecxs  snail  be 
per  1  orn.ed. 


4-lb.l  Identify  System  Functions:  BLOCK  3 


Are  all  functions  (PROCESSES)  defined  in  operational  terms  as 
opposed  to  solution  oriented  terminology  such  as  data 
Processing  terms?  Remove  or  rename  all  functions  which  imply 
"now-toM . 

Are  the  functions  Decked  Dy  studies  or  the  ilice  which  resolve 
technical  risks?  Remove  all  functions  which  are  not  feasible 
or  analyze  the  risks  and  resolve  any  uncertainty. 

Are  all  source  references  (SOURCES)  identified  for  each 
function? 

nave  high  level  functions  been  Droken  down  into  tne  lowest 
level  functions  (functional  primitives)?  oo  all  functional 
primitives  have  a  PROCEDURE  defined? 

Can  any  functions  be  consolidated?  Can  duplicated  or  similar 
functions  be  eliminated  or  consolidated?  ' 

Have  all  traces  (TRACE-KEYS)  been  defined  for  each  functional 
primitive? 


4.10.2  Organize  Functions  into  a  Hierarchical  Structure:  BLOCK  4 


Does  the  hierarchical  structure  contain  all  functions  defined? 
mat  Is,  are  all  PART/SUBPART  relationships  entered  and 
correct? 

Does  the  sum  of  the  activities  of  each  set  of  lower  level 
functions  represent  the  activities  of  the  function  at  the  next 
higher  level  in  the  functional  hierarchy?  Are  there  any 
missing  lower  level  functions? 

Does  eacn  level  of  tne  functional  Hierarchical  structure 
consist  of  2-7  functions?  If  not,  can  tne  hierarchy  be 
restructured? 
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4  .  1  b  .  J  Identity  .System  Constraints:  BLOCK  b 


nave  ail  constraints  (aemGo,  ATl'KlbUTES,  haPEELS)  been 
associated  *'itn  specltic  function  levels  m  tne  functional 
nlerarcny?  Are  constraint  requirements  applieo  to  tne 
appropriate  functions? 

Are  tne  constraints  identltieu  by  type:  or-,  py  - ,  op-,  on-  ? 

no  constraints  nave  source  document  references  (SOURCE^) 
defined?  Each  constraint  snail  be  oac<ea  by  documentation 
*mcn  provides  tne  rationale,  or  feasibility  for  tne 
constraint.  If  no  source  reference  is  identified  or 
availade,  tne  constraint  snail  be  eliminated. 

uo  any  combinations  of  constraint  requirements  imposed  on  tne 
functions  result  In  excessive  or  unrealistic  engineering 
requirements,  thereby  increasing  costs,  technical  and  schedule 
riSKS  during  tne  system  development  ar.d  system  life  cycle? 
inhere  uncertainty  or  conflicts  exist,  furtner  analysis  shall 
be  performed.  as  a  result  the  conflicts  snail  De  removea  oy 
eliminating  or  adjusting  tne  conflicting  requirements. 

is  eacn  constraint  requirement  defined  In  quantifiable  terms: 
single  values  or  range  of  values,  including  units  of  measure, 
limits,  accuracy  or  precision,  and  frequency? 

Have  constraints  been  overspecified?  Excessive  constraints 
eliminate  design  flexibility. 

Have  all  traces  (TRACE-KEYS)  been  defined  for  eacn  constraint? 


4. lb. 4  Identity  System  Using  Activities  BLOCK  b 


nave  all  using  activities  (organizat ions ,  operational  units, 
or  positions)  been  identified  and  related  to  associated  inputs 
and  outputs? 


Have  ail  using  activity  source  references  (SOURCES)  and  traces 
1 1  R  A  C  h  -  K  L  ?  S )  rer>n  identified? 


4 . l b . b  identify  External  System  input s-Uutputs :  block  1 

Have  all  external  system  i/u  been  identified? 

Have  all  required  external  I/O  formats  (messages,  etc.)  been 
identified  ano  uescrioed? 


LOGICON 


page:  4y 


Are  all  external  l/u  associated  with  using  activities  l  BLOCK 
oj  and  functions  i  BLOCK  o  l '? 

Are  all  external  I/O  source  document  references  ISUURCES)  and 
traces  (TRACE-KEYS)  Identified* 


4. lb. fa  Perform  Information-Flow  Analysis:  BLOCK  a 


is  there  an  information-flow  sequence  defined  for  every 
external  output  desired?  Can  every  external  output  De  traced 
to  Inputs? 

is  eacn  information-flow  sequence  complete  ana  logically 
correct?  Tne  Information  How  shall  Indicate  only  the 
relationship  between  system  functions  ana  system  Information 
(external  and  internal  system  l/U)  and  snail  not  imply  any 
lapse  In  time  or  intermediate  I/O  being  useo,  derived,  or 
updated. 

Are  all  Information-flow  relationships  ( USES ,  DERIVES, 
UPDATES,  GENERATES,  RECEIVES)  described  as  appropriate  in  eacn 
intormation-flow  sequence? 

Are  all  using  activities  (BLOCK  fa)  associated  with  system 
external  I/O? 

Is  eacn  information-flow  sequence  referenced  to  source 
documentation  ( SOURCE)  wnich  established  tne  need  tor  the 
information-flow  sequence  as  well  as  resolves  any  uncertainty 
or  technical  rlsxs? 


4.ib. 7  Structure  System  Information:  BLOCK  y 


Does  tne  information  hierarchy  structure  contain  all  external 
and  Internal  I/O  as  described  in  tne  source  documentation 
(SOURCES)? 

Does  the  sum  of  the  I/O  at  a  given  level  represent  tne  total 
contents  of  tne  i/o  at  the  next  higher  level  In  tne  hierarchy? 

do  the  l/O  structures  represent  tne  contents  of  each  external 
i/u  (SET,  INPUT,  OUTPUT,  GROUP/element) ?  Each  internal  I/O 
IStl,  ENTITY,  GRDUP/ELEMENT) ? 


Are  traces  IT RACE-KEY  S)  complete  for  all  I/O? 
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4 . 1 5  •  b  Perform  Control-Plow  Analysis:  BLOCK  10 


Is  each  control-flow  sequence  complete  and  logically  correct? 
>«o  lapse  in  time  or  intermediate  activity  snail  oe  implied 
between  functions  in  tne  control-flow  sequence. 

Are  all  conditions  which  determine  tne  flow  direction 
aescrioed  using  tne  control-flow  relationships:  TRIGGERS, 
UTILIZES,  CONDITION? 

Are  initial  control  flows  primarily  functional  flows?  Tnat 
is,  are  TRIGGERS  and  UTILIZES  relationships  primarily  used? 

is  each  control-flow  sequence  referenced  to  source 
documentation  (SOURCES)  wnicn  estaDlisnes  the  need  and 
rationale  for  the  control-flow  sequence  as  well  as  resolves 
any  uncertainty  of  technical  risks? 


4.15.9  perform  Test  Analysis:  BLOCK  11 


Are  all  test  points  (EVENTS)  Identified? 

Are  source  references  (SOURCES)  to  Test  Cases,  Test  Plans  and 
Procedures,  Quality  Assurance  Provisions  etc.  identified  for 
each  test  case  or  point? 

Are  test  points  associated  with  the  control  flows?  That  is, 
is  every  test  point  related  to  at  least  one  PROCESS  in  the 
control  flow  using  CAUSED  BY/TRIGGERS  statements? 


4.15.10  Prepare  Specification  Documentation:  BLUCK  12 


Have  all  requirements  defined  during  BLUCKS  i-11  been 
incorporated  Into  tne  appropriate  specification  paragraphs  as 
figures  or  appendices  witnout  cnange? 

Has  supplemental  text  been  restricted  and  concisely  written  as 
described  in  BLOCK  12? 

Has  supplemental  text  been  reviewed  to  identity  any  conflicts 
oetween  the  text  and  tne  system  requirements  defined  in  blocks 
j-11?  Remove  any  conflicts  in  the  text  or  reaccompiisn  tne 
analysis  to  resolve  deficiencies. 
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-4. lb. 11  perform  Traceability  Analysis:  BLOCK  11 


nave  suuhCtS  oeen  defined  tor  ill  system  requirements  as 
specified  in  tne  Requirements  tnqineerlnq  Plan  IBLUCK  i\  ? 

have  all  system  requirements  «nicn  nave  no  source  references 
oeen  eliminated?  It  tne  requirement  has  no  sources,  it  Is  not 
a  user  requirement. 

nave  TRACl-KEI'S  oeen  de  tinea  which  snow  tne  allocated 
requirements  In  otner  models  or  specitications  as  required  oy 
tne  Requirements  Engineering  Plan  IBLUCK  i) ( 


4.10  Manage  Requirements  Engineering  Activities  lblock  lb] 


Tne  preceding  o LUCKS  describe  tne  activities  to  oe  performed  In 
developing  a  logical  model  ot  system  requirements.  During  tne 
modeling  activities,  project  and  tecnnicai  managers  often  need 
information  wnicn  describes  (1J  the  status  ot  tne  modeling 
activities  from  wee«  to  week,  (21  the  quality  of  tne  requirements 
detinitlon  as  maintained  in  tne  requirements  data  oase,  and  (i) 
the  size  and  growth  of  tne  requirements  data  base.'  Most  analyzer 
reports  described  in  the  preceding  BLOCKS  serve  tne  requirements 
engineers  in  determining  the  consistency  and  completeness  ot  the 
detinitlon  and  can  oe  used  to  document  the  system.  mere  are, 
however,  several  reports  which  are  more  specifically  intended  for 
project  and  technical  management  of  the  requirements  engineering 
activities . 

He ports  wnicn  aid  monitoring  the  progress  being  made  are  the 
Attribute  Report,  Data  Base  Summary  Report,  and  Data  base  Status 
Report,  tacn  of  these  reports  provides  statistics  oh  tne  nuraoer 
ot  objects  and  relations  nips  between  objects  in  tne  requirements 
data  Dase.  User  options  in  these  reports  allow  a  variety  of 
displays  (counts  and/or  percentages)  which  can  oe  used  from  week 
to  week  or  over  longer  periods  of  time  to  track  various  aspects 
ot  tne  requirements  data  base.  For  instance,  tne  following 
status  ATTRIBUTES  can  oe  used  by  the  requirements  engineer  to 
make  a  statement  about  tne  quality  of  the  requirements  (PROCESS, 
i  ;hui,  OUTPUT,  etc.)  in  tne  r  egu  i  r  err  ents  oata  oase: 


Attribute- La me  Attribute- Value  Meaning 


status 

amoi  g 

status 

c  o  in  p  1 

status 

lncpl 

status 

incs  t 

status 

redun 

amblgious 
complete 
incompie  t  e 
inconsistent 
redundant 


A 
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these  vi  i'Mt>uas  can  be  associated  with  any  requirement  (object). 
Tne  following  example  is  similar  to  tne  performance  AllHiBUTL 
exam  ple  shown  in  (BLOCK  SJ  : 

H  ACCESS  valldate-time-curds; 

A  f  1  H  i  Bu  l'E  s  AHf;  status  incomplete; 


in  tne  above  example,  tne  AlTklbUl'fc.  is  not  turtner  described 
usin j  tne  DtFiNt  section  as  was  done  in  BLUCK  b.  Decause  tne 
naming  convention  described  above  tor  the  Attribute-dames  ana 
At  tribute- Values  is  sufficient  tor  status  monitoring  purposes. 

Tne  Attribute  Keport  and  Data  Base  Status  report  display  tnese 
attributes  and  attr loute-vaiues .  The  project  or  technical 
manager  can  therefore  see  the  quality  (status!  of  tne 
requirements  snift  from  one  of  poor  quality  (amDiglous, 
incomplete,  inconsistent,  or  redundant),  as  might  be  tne  cas.e  in 
tne  initial  stages  of  the  analysis,  to  one  of  nigh  quality 
(complete)  as  the  requirements  engineering  activities  are 
tinlsned.  During  the  requirements  engineering  project,  the 
requirements  data  base  will  gradually  approach  "complete  status" 
as  attributes  are  changed  by  the  analysis '  team.  Tne  status 
attributes  not  only  report  tne  progress  oeing  made,  but  also  the 
quality  of  the  requirements  themselves  (amblglous.  Inconsistent, 
reaundant)  as  determined  oy  tne  analyst.  "As  the  counts  of  eacn 
status  attribute  cnange  over  previous  weeks,  tne  relative  growth 
of  tne  data  case  becomes  apparent.  There  are  no  analyzer  reports 
whicn  display  the  actual  physical  size  of  tne  requirements  data 
base  on  tne  computer  where  it  is  nos  ted  or  provlae  information  on 
now  much  storage  remains. 

borne  reports  aid  in  the  configuration  management  of  tne 
requirements  data  base  by  maintaining  a  nlstory  of  changes  made. 
These  are  List  Changes,  the  Name-List  and  formatted  Problem 
Statement  Keports  (with  appropriate  options  in  effect),  and  Data 
base  Status.  Tnese  reports  and  those  previously  mentioned  are 
described  in  Appendix  C  and  further  described  in  the  Analyzer 
references  In  Appendix  A. 


LOG1CON 


PAGE  5i 


APPENDIX  A 

SELECTED  REFERENCES 
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Project,  University  of  Michigan,  USAF/AFSC:  Electronic  Systems 
Division  (ESD/TOI),  Hanscom  AFb ,  MA,  March  77. 
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No.  79A51 -01 74-4,  Septeriioer  19/9. 
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APPENDIX  B 


SELECTED  LANGUAGE  FEATURES 


This  appendix  provides  a  condensed  list  of  the  language  features 
which  support  the  requirements  engineering  activities  (BLOCKS) 
described  In  tnis  guideboox.  in  general,  tne  language  features 
presented  here  will  provide  the  requirements  engineer  witn 
adequate  capabilities  which  will  make  the  requirements 
definition,  analysis,  and  documentation  process  productive  and 
meet  the  objectives  of  the  activities  expressed  in  this 
guideboox.  This  appendix  provides  a  quick-reference  list  for 
beginning  users  of  the  language  and  aids  in  determining  the 
language  features  to  be  employed,  it  is  expected  tnat  in  a  given 
application  tnis  set  of  language  objects  and  statements  within 
the  object  sections  will  be  eitner  reduced  or  expanded  to  meet 
tne  objectives  of  a  specific  application.  Tnis  list  will  provide 
a  basis  for  the  selection  process.  Further  details  concerning 
the  language  features  are  described  in  the  language  reference 
documents  available  for  the  tool  version  being  used  (.Appendix  A3. 
Availability  of  any  language  feature  which  has  changed  or  nas 
been  added  from  one  version  to' another  is  noted.  in  addition,  a 
cross  reference  is  provided  between  the  language  feature  and  the 
BLUCKS  to  which  they  apply. 

The  versions  are  denoted  by  the  following  numbers  used  in  this 
appendix: 


(3.2)  URL/URA  (CARA  or  CAD5AT),  an  Air  Force  version  of 
PSL/PSA,  University  of  Michigan  (ISDQS  Project),  1974. 

(3.2X3  3.2  plus  extensions  and  modifications  made  by  Logicon 
inc.  for  the  Air  Force,  197 b. 

(4.2)  PSL/PSA  version  available  from  the  university  of 
Michigan  (ISD05  Project),  1977-1978. 

(5.1)  Most  recent  version  of  PSL/PSA  available  from  the 
university  of  Michigan  (ISDUS  Project),  197«-197y. 


LOGICON 


Paul  ')'» 


me  toiiowinq  sections  loojectsJ  are  container  in  this  appendix: 


StC  1'iUNS 

C  K  O  S  i>  i 

KfcFLKLNCt 

AITKIHUIK 

dLOCKS 

b  and  lb 

CUUDl'liUN 

bLUO 

lu 

LLfcM&N'l 

BLOCKS 

7  - 

9 

L  Nil  1  { 

BLOCKS 

8  - 

9 

LVfcM 

BLOCK 

1  1 

LKUuP 

BLOCivS 

7  - 

y 

INPUT 

BLOCKS 

7  - 

9 

1 1*  1  tKK  ACL 

BLOCK 

b 

Ne.Nl) 

BLOCK 

b 

UU1PUT 

bLOCKS 

7  - 

9 

BKOCLSS 

BLOCK 

i 

S£1 

BLOCKS 

7  - 

y 
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\  .  k.  M-.Li-CTEi’  ij  A  f-  Ci  L)  A  G  e.  t- E  A  I  UK r.b  CjMlUN  10  ALL  LlLUijMj  (U^Jr.LlG; 


A1  i  k  1  bUTK  o  A  k  t.  attribute-name-l  at  t  r  1  bu  t  e- va  1  ue- 1  ,  IbLUCKL  b,ioj 
(  *t.tr  ) 

•  • 

•  • 

attribute- a  a  n.  e-n  nttrioute-value-n;  Cl) 

DtoCKleTlON  (desc); 

. - .  (2) 

- comment-entry - 

sY'.um.m  (syn)  synonym-name (s ) ;  (-)) 

is  El ’.ORD  (Key)  keywora-name(s); 

S  u  u  k  C  E  (src)  source-identifier(s); 

TRACE-KEY  C  t  ice  y )  t  r  ace-1  dent  1 1  ie  r  C  s  ) ; 


Stt-^LMG  (sm)  memo-name  ( s  ) ; 


NU  i  t  s: 

Cl)  ATTRIBUTES  tor  an  object  are  initially  Identified 
( A  T 1 R I  B  U 1 E  -  N  A  M  E  and  A  XTRI  BUTE- V  ALUE  only)  within  the 
section  (object)  to  wnlch  they  apply  by  use  of  the 
ATTRIBUTE  (attr)  statement.  Tne  ATTRIBUTE  section  (2.0) 
provides  the  means  of  elaborating  on  tne  ATTRIBUTE 
througn  use  of  tne  statements  such  as  desc,  syn,  key, 
src,  tkey,  and  sm. 

C2)  Text  descriptions  (comment-entries)  can  be  used  to  expand 
upon  tne  object  wnere  tne  syntax  of  tne  language  does  not 
suffice.  Comment-entries  are  free  format,  72  characters 
per  line,  maximum  of  t>u  lines.  Comment-entries  should  oe 
limited  In  most  applications  since  the  data  Dase  grows 
considerably  with  tneir  use.  Succinct  comment-entries 
are  advised. 

CD  wnere  requirement  names  (objects)  in  tms  appendix  end  in 
"(s);",  more  than  one  ODject  may  oe  identified.  Eacn 
object  is  separated  by  a  comma  and  the  last  object  ends 
witn  a  colon. 
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A'fTHlhUTt,  Sfc.CH  UA  IKI,UL>..»  '>  ind  JSJ 


A ii H 1 b  Hi E  s  are  used  to  o  e  1 1  n  e  other  aspects  about  an  object  w  n  i  c  n 
cannot  oe  done  oy  otner  statements  provided  in  the  language. 
A  r  t  H I  6UTES  tor  an  object  are  initially  iaentltied  t  ATTk  1  BdTc.-.’«  A  ME 
and  ATTRIBUTE-VALUE  only)  ntnin  the  section  (ODject)  to  which 
they  apply  by  the  use  ot  tne  ATTRIBUTE.  (attri  statements  as 
Indicated  In  l.C.  This  section  proviaes  the  means  ol  elaborating 
on  tne  previously  identified  AilRibui'E  through  use  of  any  of  the 
statements  within  tne  AI'lKiBUIE  section  (i.e.,  aesc,  syn.  Key, 
src,  tKey,  sm); 

mere  are  two  ways  ATTRIBUTES  are  used  in  this  guueDootc:  (l)  as 
one  means  ot  defining  corutralnts  LaLUCK  bj  ana  lyj  to  aetine 
status  attributes  18LOCK  lb]  .  Constraint  and  status  attributes 
can  ee  defined  by  using  the  following  naming  conventions: 


Constraint  A ttriou tes:  [ BLOCK  bJ 

Attribute-Name  Attribute- Value 


Pf-attr ibute-name 
py-attnbute-name 
op-attrloute-name 
dn-attribute-name 


performance -constraint 
physical-constraint 
operability -constraint 
design-constraint 


Status  Attributes:  [BLOCK  lbJ 


Attr ioute-Name 

status 

status 

status 

status 

status 


Attribute- value 

amblg 
compl 
incpl 
incst 
r  edun 


Meaning 

ambigious 

complete 

incomplete 

inconsistent 

redundant 


DEfciNfc  (def)  attribute-name  ATTRIBUTE;  (1) 


I  t 
I  desc,  syn.  Key,  src,  ticey,  sm  i 
I  I 
I  See  Section  l  I 
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NOT  t 

11)  Versions  3.2  and  4.2  nave  a  DE'F iNt  section  tor  descnolnj 
certain  objects  in  greater  detail.  Tne  AllKiBUre  is  one 
ODject  in  3.2  and  4.2  that  can  De  expanded  upon  using 
tne  DEFINE  section  as  shown  aoove.  in  version  5.1  there 
is  no  DEFINE  section  and  the  ATTRIBUTE  has  oecome  a  new 
section.  Version  5.1  requires  the  DLfLNc.  (act  j  to  preceea 
eacn  section.  Thus  "PROCESS  process-name;"  oecomes 
"DEFINE  process  process-name;".  cnts  appendix  retiects 
tne  tor mat  for  each  language  section  whicn  is 
compatabile  with  versions  3.2  ann  4.2;  users  or  version 
5.1  will  nave  to  ado  "DEFINE"  preceaing  eacn  section 
header  statement. 
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i.  cuNomuo  section  iblucn  ioj 


This  section  provides  tne  means  to  define  the  conditions  whicn 
control  tne  direction  of  system  control  flow.  The  condition  may 
be  initially  identified  (condition-name  only)  under  tne  PROCESS 
section  uy  tne  use  of  tne  TRIGGERED  WHEN  relationship.  Tne 
condition  section  provides  a  means  of  elaborating  on  tne 
condition.  In  addition,  tnls  section  aliows  a  previously 
unidentified  condition  which  was  omitted  in  tne  associated 
process  definition  to  be  identified  (named),  associated  witn 
functions  (PROCESSES)  and  described. 


C U N u 1 X 1 C a  (cond)  condition-name  (BLOCK  1UJ 


I  I 
I  attr,  oesc,  syn.  Key,  src,  tKey,  sm  l 
I  I 
I  See  Section  1  I 


Becoming  TRUE  TRIGGERS  (becg  t  trys)  process-name ( s ) ; 
becoming  FALSE  1  RIGGERS  (oecg  t  trgs)  process-name ( s j  ; 


TRUE  WHILE  (t  Whl); 

- - comment-entry — 

FALSE  WHILE  (t  wnl)? 
- - comment-entry-- 
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4.  c.L  E  M  E  N  r  SECfiUN  [BLOCKS  /-y) 


t  L  c.  h  t  A  r  iele)  s y  s  t e.r.-i n  t or ma 1 1  on-name ; 


l  bLUC  k  5  7  -9  J 


I  I 

I  attr,  desc,  syn,  K.ey,  src,  txey,  sn:  i 
I  I 
I  See  Section  1  I 


CUN 'IAIN  ED  IN  Ccntd)  (  group-) 

{  entity-) 

<  Input-) 

<  output- )  name  {  s  ) ; 

dehived  b Y  ( dr  vd )  process-namets);  (.1) 

UPDATED  BY  Cupddj  process-name ( s ) ;  1 1 ) 

used  BY  Cusea)  pr oces s -name ( s ) ;  (1)(2J 


IbLOCK  9 J 


[BLOCK  b J 
[bLOCK  b] 
[BLOCK  bj 


VALUc-S  ARE  (vai) 


value-name( s)  [THRU  value-name( s) j  ; 


[BLOCK  8 ] 


NOTE 

[ 1 )  See  note  [a)  under  tne  PkOCESS  section 

(2)  EMPLOYED  BY  Cepid)  in  version  5.1 


i 


L0C3C0M 


PAGE  o2 


5.  fcMIllt  SECTION  [BLOCKS  b-9i 


tMllK  Cent)  lnternai-miormation-name; 


IBLUCKS  8  -9  J 


I  I 


l  attr, 
l 

1 

desc,  syn,  Key,  src,  tccey,  sm 

see  section  1 

1 

1 

1 

FA  NT  OF 

(part)  entity-name; 

l  BLOCK 

9] 

subparts 

ARE  isuop)  en ti ty-name ( s )  ; 

[BLOO 

9  J 

CD  INSISTS 

OF  (csts)  <  group-) 

[BLOCK 

9] 

[element-lnameCs); 

CONTAINED  IN  (cntd)  set-name C s ) ; 

CD 

[BLOCK 

9  j 

DENI VcD 

BY  Cdrvd)  process-nameCs) ; 

C2) 

[SLOCK 

8J 

OPDATED 

BY  C updd j  process-name(s); 

C  2  ) 

[BLOCK 

8) 

USED  B Y 

iusea)  process-namels) ; 

C  2  J  (  3  ) 

,  [BLOCK 

b) 

NOTES 


Cl) 

COLLECTED 

IN 

Ccltd) 

in 

version 

5.1 

C  2  ) 

See  note 

(5) 

under 

tne 

PROCESS 

section 

(J) 

EMPLOYED 

BY 

tepid) 

in 

version 

5.1 
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/ 


o.  tvtNi  statON  ibluck  in 


EVtNl  lev)  event-name; 


l  t 
l  attr/  desc,  syn,  key,  src,  tKey,  sm  I 
I  I 
I  See  Section  1  I 


IBLOCK  1 1 J 


PArtI  OF  ipart)  event-names;  IBLOCK  11J 

SbbPAKl'S  AKL  Isudp)  event-namels);  IBlOCK  li) 


C AUSfcD  BY  ICSd) 
ihlviGLHS  (trgs) 


process-name(s); 
process -name(s); 


IBLOCK  lli 
IbLOCK  lli 
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/.  GKOU P  SECTION  1 6 LUCK S  7-9J 


GKUUP  Cgr)  system-intormation-name; 


l BLOCKS  7-9 J 


I  I 
l  attr,  desc,  syn,  key,  src,  tkey,  sm  I 
I  I 
I  See  section  1  I 


consists  OF  tests)  t  group-) 

{eleaient-inamets); 


[BLOCK  9J 


contained  in  tentd)  {entity-) 

{  input-) 
{output-) 

{  group-)namets) ; 

dekived  by  tdrvd)  process-name t s ) ? 
updated  BY  tupdd)  process-namel s) ; 
used  bY  {used)  process-namets) ? 


(1) 

(1) 

(i)(2) 


l BLOCK  9) 


[BLOCK  BJ 
l B  LUCK  BJ 
[BLOCK  BJ 


NOTES 

(1)  See  notes  tb)  under  the  PHOCESS  section 
(.2)  EMPLOYED  BY  tepid)  in  version  b.l 
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b.  INPUT  StCHOii  U'LOCK  7-9  J 


INPUT  (inp)  external-lnf ormation-name;  [BLOCK  li 


I  I 
I  at  t  r ,  desc ,  syn ,  key,  src,  tkey,  sm  i 
I  t 
I  See  Section  1  I 


CUNSISTS  OK  (CStS) 

(  group-/ 
{element->name(s); 

[BLOCK 

9) 

CUNTAINLO  IN  tcntd ) 

set-name ( s ) 

(l) 

[ BLOCis 

9  j 

PARI  OF  (part)  input 

-name; 

[BLOCK 

9) 

SUoPARTS'AKL  (suop) 

input-name (s ) ; 

[BLOCK 

yj 

GENtRATEO  BY  (gend) 

lnterface-namets); 

[BLOCK 

b) 

KLCtIVED  BY  ( r CVd ) 

process-name ( s ) ; 

[BLOCK 

a) 

US LU  BY  (used) 

process -name  i s ) ; 

(2)  (3) 

:  [BLOCK 

b) 

NOILS 

(1)  COLllctlo  in  (cltd)  in  version  5.1 
ii)  tMPLO i tl)  BY  (epid)  in  version  5.1 
( 3 )  See  note  (b)  under  the  PROCESS  section 
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y.  INTERFACE  cjfcCHO^  IbLOCK  bJ 


Interface  (intf)  using-activlty-name(s); 


I  I 
I  attr,  desc,  syn,  Key,  sre,  t<ey,  sm  I 
«  I 
I  See  Section  1  I 


UJ  IbLOCK  bJ 


part  Of  (part)  using-activity-name?  IbLOCK  6j 

SUbPAKTS  AHE  ( suop)  using-activity-name(s);  IdbOCK  t> ) 


GENERATES  (gens)  input-name(s) ; 
receives  (revs)  output-nanei s ) ; 


IbLOCK  b,  dl 
IbLOCK  6,  dj 


NOTE 

ll)  The  PROCESS  can  also  De  used  to  represent  using  activities 
in  lieu  of  INTERFACES ,  see  BLOCK  b. 
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10.  MEMU  SECTION  IbLUCK  d) 


The  MEMO  section  can  be  used  In  two  ways:  c 1 )  as  a  means  of 
recording  analysts  notes  (Note  Memo)  ,  and  (2)  as  one  means  of 
describing  system  constraints:  performance,  physical, 
operability,  and  design  requirements  (Constraint  Memo),  see  BLOCK 
5.  The  name  of  the  constraint  memo  'includes  tne  prefixes  as 
indicated  in  note  1. 


memo  (memo)  prefix-memo-name;  (1) 


I  I 
I  attr,  desc,  syn.  Key,  tKey,  src  | 
»  i 

I  see  Section  1  I 


applies  TO  (app)  non-memo-name;  (2) 


[BLOCK  5) 


1  [BLOCK  5) 


NOTES 

(1)  The  prefix  is  used  to  distinguish  the  various  constraints, 
when  the  MEMO  is  being  used  to  define  "a  constraint  the 
prefixes  identified  below  shall  be  applied.  For  note  memos 


the  p 

refix  is  omitted 

pf- 

performance 

PY- 

physical 

op- 

operability 

dn- 

design 

(2)  where  the  MEMO  is  used  to  define  a  constraint,  the  name  of 
the  memo  (non-memo-name)  shall  be’ the  process-name.  This 
identifies  the  function  that  is  being  constrained. 


PAGt  0/D 


luu.  UUtHUl  itO  iDt.  Ilm.JCkS  /-y) 


uu/him  tout)  externai-intormation-ndme;  CBLuCK  /J 


I  I 
i  dttr,  desc,  syn,  Key,  src,  txey,  sm  l 
I  I 
I  see  Section  i  I 


CONSISTS  Ut  ICStS) 

l  group-) 

[element-) name l s ) ; 

IBLOCK 

yj 

Cum  1 A 1 NED  In  lento) 

set-name  is); 

1 1 ) 

[BLOCK 

yj 

baki  ut  (part)  output-name; 

l BLOCK 

yj 

SUtt'AKTS  A«t  (SUDP) 

output-namels) ; 

l BLOCK 

yj 

GtNfcKATED  BY  I3end) 

process-name  is); 

[BLOCK 

rtJ 

uthivtu  b¥  lorvaj 

process-name  is); 

U) 

[BLOCK 

bj 

KtCciVhD  bx  '  Ircvoj 

mtertace-na.iieis) ; 

IdLOCK 

a  j 

NUltS 


UJ  COLLKCTtD  IN  leltd)  in  version  b.l 
(2/  See  note  (5)  under  tne  hhuckss  section 
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11.  PROCESS  SECTION  IHLOCK  JJ 


The  PROCESS  section  is  used 
functions.  Tne  following  is 
language  features  which  are 
engineering  activities  (SLOCKS) 


to  describe  tne  target  system 
a  summary  of  selected  PROCESS 
applicable  to  tne  requirements 
described  In  this  guidebook. 


PROCESS  (prc)  process-name; 


111  [BLOCK  31 


I  I 

I  attr ,  desc,  syn,  key,  tkey ,  src,  sm 

i  i 

I  see  Section  1  I 


PART  OF  (part)  process-name; 
SUBPARTS 'are  (subp)  process-name(s) ; 


[BLOCK  4 J 
[BLOCK  4} 


TRIGGERS  (trgs)  process-name(s) 

TRIGGERED  BY  (trgd)  process-riaroe( s) ; 

TRIGGERED  WHEN  condition-name  BECOMES  (TRUE  (Z) 

(FALSE; 


[BLOCK  10) 
[BLOCK  10) 
[BLOCK  10) 


UTILIZES  (utis)  process-name(s) ; 
UTILIZED  BY  (utld)  process-name (s ) ; 


[BLOCK  10J 
[BLOCK  10) 


USES  (uses) 


USES  (uses) 


(  set-) 

(  input-) 

(  entity-)name(s) ; 
i  group-) 

(element-) 

(4) (5) 

[ 

(  (DERIVE) 

[  TO  (  ) 

(  (UPDATE) 

l 


(  set-) 

(  input-) 

(  entity-)name(s) 
(  group-) 
(element-) 


(3) (fa)  [BLOCK  8) 


[BLOCK  8) 

(  set-)  ) 

(  output-)  ) 

(  entity-) name(s)  )? 
(  group-)  ) 

(element-)  i 
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DERIVES 

(drvs) 


(BLOCK 

8 ) 

Cb! 

{ 

set-! 

1 

( 

set-! 

i 

( 

output- t 

l 

( 

Input-! 

) 

( 

entity-iname(s) 

l 

USING 

< 

entity-!name(s) 

J ; 

( 

group-! 

l 

( 

group-! 

j 

(element-! 

( 

(element-! 

) 

[BLOCK 

8  J 

Cb) 

(  set-!  [ 

( 

set-! 

) 

(  entity-!  1 

( 

Input-! 

) 

UPDATES 

(  group->name(sl  [ 

USING 

( 

entl ty-! name (s ) 

) ; 

( upds  J 

(element-!  1 

( 

group-! 

) 

t 

(element-! 

) 

GENERATES 

(gens)  output-name ( s ) ; 

[BLOCK 

8) 

RECEIVES 

(revs)  input-name! s ) ; 

[BLOCK 

8  J 

PROCEDURE? 

- comment-entry - (b)  [BLOCK  iJ 


noies: 

(1)  Throughout  this  appendix  the  process-name  is  the  actual 
name  of  the  function  identified  during  BLOCK  i. 

12)  See  Condition  Section,  i.o. 

(3)  EMPLOYS  (epls)  in  version  5.1.  The  compound  forms, 
USES-TO  DERIVE  and  USES-TO  UPDATE  are  oetter  as 
aescrioed  In  note  (5)  below. 

(4)  This  form  is  complementary  to  the  DERlvES-usiNG  and 
UPDATES-USING  statements  below. 

(5)  The  PSA  Information  flow  reports  (Picture,  Extended 

Picture!  are  more  meaningful  when 'using  tne  compound 
PSL  statements  verses  tne  simplex  forms  ot  lust  USES, 
DERIVES,  and  UPDATES.  In  addition,  compouna  forms  can 
be  expressed  under  the  set,  INPUT,  output,  ENTITY, 
GROUP,  and  ELEMENT  sections.  However,  it  is  recommended 
tnat  the  compound  uses  be  restricted  only  to  tne  PROCESS 
section.  Therefore,  compound  forms  nave  been 

presented  only  in  tnls  pkucess  section. 

(b)  Tne  PROCEDURE  statement  is  used  to  describe:  (A)  the 
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sequence  ot  operations  needed  to  implement  tne  function 
( process )  t  e.q.  structured  English,  (hi  uecisiori  rabies, 
tc)  Decision  Trees.  PROCEDURE  statements  snould  re 
defined  for  functional  primitives  only,  l.e,  tne 
functions  at  tne  lowest  level  in  tr.e  functional 
nierarcny.  Tne  use  of  comment-entries  to  define  a 
PROCEDURE  should  De  limited  just  as  wltn  DESCRIPTIONS, 
see  note  2,  Section  l. 
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12.  SET  Sfc.CriON  [BLUCKS  7-9) 


St  I  information-name; 


[BLOCK  n 


I  i 
t  attr,  desc,  syn,  key,  src,  tkey,  sm  i 
I  I 
l  See  section  1  I 


SUBSET  OF  (sst)  set-name(s); 

[BLOCK 

9J 

SUS6ETS 

ARE  (SStS) 

set-names ( s ) ; 

[BLOCK 

yj 

CONSISTS 

OF  (csts) 

{entity-) 

CD 

[BLOCK 

9) 

{  input-) 

{output-) name  Cs ) ; 

USED  BY 

(used) 

process-name(s) ; 

(2) ( 3} 

[BLOCK 

8J 

DERIVED 

6y  (arvd) 

process-name  is); 

{  2 )  ' " 

[BLOCK 

8) 

UPDATED 

BY  (updd ) 

process-namei s) ; 

(2) 

[BLOCK 

8J 

NOTES 

Cl)  COLLECT IONS  OF  <cltn)  in  version  S.l 
(2)  See  note  (5)  under  tne  PROCESS  section 
Ci)  EMPLOYED  BY  (epid)  in  version  5.1 
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ApHt.iinx  c 


AHSTKACIS  ue  AWAL1ZEK  KtPGKXS 


This  appendix  contains  a  list  of  PSA  reports  and  a  brief 
description  of  each.  This  list  represents  a  composite  of  reports 
available  from  tne  various  versions  of  the  analyzer  now  in  use. 
versions  are  denoted  oy  the  following  numbers  adjacent  to  the 
report  tities: 


(3.2)  URL/liRA,  an  Air  Force  version  of  PSL/PSA,  University 
of  Michigan  (ISDOS  Project),  1974. 

C3.2X)  3.2  plus  extensions  and  modifications  made  by  Logicon 
inc.  for  tne  Air  Force,  197b . 

(4.2)  PSL/PSA  version  available  from  tne  university  of 
Michigan,  1977-1978. 

( b , 1 )  PSL/PSA  most  recent  version  available  from  the 
University  of  Michigan,  1978-1979. 


Some  report  names  have  been  changed  as  new  versions  were 
released.  Many  reports  include  new  capabilities  over  previous 
releases.  The  descriptions  for  each  report  provided  below 
encompass  the  most  recent  capabilities.  Refer  to  the  description 
of  the  reports  for  the  version  available  tor  detailed 
capabilities  and  procedures  for  generating  the  reports. 

PSA  provides  the  capability  to  create  and  modify  tne  requirements 
data  base  using  various  modifier  commands  as  described  below. 
PSAalso  provides  the  capability  to  generate  reports  which  aid 
tne  requirements  engineering  activities  (BLOCKS)  as  described  in 
section  4  of  this  guidebook.  where  a  report  supports  the 
requirements  engineering  activities  (BLOCKS)  described  in  this 
guidebook,  applicable  BLOCKS  are  denoted  at  the  end  ot  tne  report 
description.  In  the  following  paragraphs,  upper  case  words  are 
used  to  indicate  the  special  PSL/PSA  reserved  words  for  objects, 
relationships,  and  properties  ot  tne  target  system  model.  For 
instance,  a  function  is  represented  by  tne  PSL  statement  PROCESS. 
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l.o  Modifier  Commands 


Combine  (4.2M5.1) 

Allows  the  requirements  engineer  to  combine  tne  Inf ormat ion 
for  two  objects  in  tne  requirements  data  base  and  record  tne 
combination  as  one  object.  A  record  of  tnis  change  Is 
produced  In  the  form  of  the  Combined  Names  report.  IA11 
BLOCKS] 

Change-Type  (3.2) 

Change-Name-Type  (4.2M5.1) 

Allows  the  requirements  engineer  to  change  tne  object  type 
defined  in  the  requirements  data  base.  A  record  of  this 
change  is  generated  In  the  form  of  the  Change-Type  report 
(3.2)  or  Change-Name  Type  report  (4.2,’  ana  0.1).  (All 
BLOCKS] 

Delete  (3.2) 

Delete-Name  (4.2M0.1) 

Allows  the  requirements  engineer  to  delete  an  object  name  or 
list  of  names  from  the  requirements  data  base.  when  a  name 
is  deleted  all  of  its  relationships  to  other  object  names  in 
the  data  base  are  also  deleted.  A  record  of  the  cnange  is 
generated  in  tne  form  of  the  Deletion  report  (J.2)  or  Delete 
Name  report  (4.2  and  5.1).  (All  BLOCKS] 

Delete -Comment- Entry  (3.2)(4.2)(0.1) 

Allows  tne  requirements  engineer  to  delete  from  the 
requirements  data  base  narrative  text  (comment-entries) 
associated  with  an  object  or  list  of  objects.  A  record  of 
the  change  is  generated  In  the  form  of  the  Deleted  Comment 
Entries  report..  (All  BLOCKS], 

Delete-PSL  ( 3 . 2 )  ( 4 . 2) ( 5 . 1 ) 

Allows  the  requirements  engineer  to  dejete  selected  language 
statements  in  tne  requirements  data  base.  A  record  of  tne 
cnange  is  gen  ted  in  tne  form  of’ the  Deleted  PSL  report 
(3.2,  4.2)  or  jelete-PJL  Source  Listing  and  Cross  ^e£erenco 

Keports  (5.1).  (All  BL0CK5J 

Input-Layout  (5.1) 

Allows  the  requirements  engineer  to  enter  LAYOUT  comment 
entries  in  a  format  wmch  ran  be  processed  by  the  LAYOUT 
command.  A  column  number  heading  is  given  tor  use  during 
input  of  LAYOUT  comment  entries.  The  Input  Layout  report  is 
generated  to  document  tne  LAYOUT.  (bLOCK  /) 


LOG1CON 


PACE  /a 


Allots  tne  requirements  engineer  to  add  r equ l  r  enen  t  s  to  tne 
requirements  data  case.  A  record  of  tne  additions  is 
generated  in  the  form  ot  the  As-ls  Source  Listing  (3.2)  or 
lnout-PSL  source  Listing  ana  PSA  Cross  Reference  reports 
(4.2  ana  b.l).  [Ail  BLOCKS i 

Problem-name  (b.l) 

Allows  tne  requirements  engineer  to  enter  tne  name  ot  the 
problem/project  into  tne  requirements  data  case  in  order 
tnat  tne  neadings  ot  the  PSA  reports  #111  contain  the  na.re 
ot  tne  project.  Tne  Problem  Name  report  is  generate.!  cc 
document  tne  change  of  the  project  name.  (.block  lbj 

Puncn-Comment- Entry  C3.2H4.2J  (b.l) 

Allows  the  requirements  engineer  to  retrieve  from  tne 
requirements  data  base  only  tne  narrative  text 
(comment-entries)  tor  specified  objects.  me  retrieved 
comment  entries  are  listed  on  the  Punched  Comment  Entries 
report  ana/or  output  to  a  host  system  flic.  [All  Block S J 

Rename  (3.2) 

Change-Name  (4.2)(b.l) 

Allows  the  requirements  engineer  to  change  the  name  ot  an 
object  in  the  requirements  data  base.  Tne  Rename  report 
(3.2)  or  Change-Name  report  (4.2  and  5.1)  is  produced  as  a 
record  of  tne  cnanges.  IA11  BLOCKS) 

Replace-Comment- Entry  (3.2)(4.2)(b.l) 

Allows  the  requirements  engineer  to  replace,  tor  a  given 
object  name,  specific  narrative  text'  (comment-entries) 
associated  with  the  object.  The  Replace  ‘Comment  Entries 
report  Is  produced  as  a  record  ot  tne  cnange.  [All  BLOCKS) 

Replace-PSL  (b.l) 

Allows  the  requirements  engineer  the  mesns  ot  replacing  PSL 
statements  In  tne  requirements  data  base.  a  record  ot  tne 
cnanue  is  recorded  ir.  tne  Hepiace-Pov.  o  .ore-  i  is  ting  ,»r.o 
Cross  Reference  reports.  [All  olucks) 
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2.0  Keport  Commands 


Assertion-consistency  (o.l) 

LIST  FORMAT :  Snows  assertions  made  (and  <jdouU  a  given 
object  nane  and  tne  overall  consistency  of  attribute  values. 
IBLUCK  1 4  J 

Attribute  Keport  ( 3. 2 ) ( 4.2 ) ( b .  l  J 

TABLE  FORMAT:  Shows  all  object  names  in  tne  aata  base  to 
whlcn  an  ATTRIBUTE  applies  and  tne  associated  ATTRlBUIc. 
values  for  the  object  names.  Aids  management,  and 
completeness  and  consistency  checking.  (blocks  b,  12,  1  ~t , 
15) 

Contents  Keport  ( 3 . 2 ) ( 4 . 2 )  ( 5 . 1  ) 

STRUCTURED-LISTING  FOR, MAT:  Snows  the  hierarcny  of  the  aata 
structure  based  on  CONSISTS(CULLECT1UN)/CONTAINEU 

statements.  Automated  consistency  checKlng  is  optional. 
Keport  snows  a  concise  listing  of  the  logical  information 
structures  to  be  nandled  by  the  target  system.  (BLOCKS  y, 
12,  14) 

Consists  Comparison  Report  (3.2) 

Contents  Comparison  Keport  (4.2H5.1) 

LIST-matkIX  FORMAT:  Used  to  detect  redundant  or  similar 
data  structures;  used  to  optimize  data  structures.  Based 
on  CQNSISTS(COLLECTION)/CONTAINED  statements.  (BLOCK  14) 

Consists  Matrix  Keport  (3.2) 

Contents  Analysis  Report  (4.2)(b.l) 

LIST-MATRIX  FORMAT:  Based  on  CONSISTS (COLLECTION) /CONTAINED 
statement;  used  to  detect  incomplete  or  redundant  data 
structures.  (BLOCK  14) 

Data  Process  Report  (3.2) 

Data  Process  Interaction  Report  (4./) 

Data-Actlvlty  Interaction  (5.1) 

MATRIX  format:  Snows  interaction  between  activities 

(RKUCbSSES/ INTER FACES)  and  data  objects  (SETS,  INPUIS, 
Outputs,  entities,  group,,  elements);  usea  to  detect 
incompletenesses  or  inconsistencies  in  data  used,  including 
data  derivation.  Also  can  De  used  in  data-flow  analysis; 
used  by  design  engineers  to  plan  tne  logic  ottarqet  system 
using  the  data-act 1 vity  dependencies.  [BLUCK  bj' 


A 
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Cdta  Base  Sumrr, ary  (J.2j(4.2)(5.i) 

TABLE  FORMAT:  Tecnnlcal  and  management  report  provlcir.j 
selected  presentation  or  progress  being  made  (.status)  on  tne 
target  system.  Compared  w  1 1  n  previous  reports;  tne  changes 
denote  progress.  Also  snows  Incomplete  (uncienned)  ODjects. 
I  BLOCKS  14,  15] 

Data  Base  Status  (3.2X) 

TABLE  FORMAT:  Technical  and  management  report  providing  a 
listing  of  requirements  (PROCESS  and  MEMO  objects)  oraereo 
according  to  the  sources  of  tne  requirements;  Tne  report 
includes  sources,  the  PROCESS/MEMO  object  name,  SYNONYM,  a 
cross  reference  to  the  structure  report,  a  status  attribute 
value  (unambigious ,  complete,  incomplete,'  inconsistent, 
redundant,  or  other  user  defined  attributes)  and  tne  number 
of  times  the  PROCESS/memo  has  Deen  revised.'  me  remaining 
columns  indicate  counts  showing  the  status  of  tne 
PROCESS/MEMO  such  as  the  number  of  synonyms,  descriptions. 
Keywords,  sources,  tracetceys,  as  well  as  flow  relatlonsnips 
(triggers,  utilizes,  derives,  receives,  etc.).  This  status 
count  is  controlled  by  user  option  and  the  display  can  be 
changed  to  satisfy  monitoring  needs.  The  report  can  be 
compared  with  previous  reports,  tne  changes  denote  progress. 
It  is  also  useful  in  cnecKing  the  completeness  of  tne 
analysis  of  existing  source  documentation.  [blocks  14,  15J 

Dictionary  Repor t C 3. 2) (4 .2 ) ( 5. 1 ) 

narrative  &  outline  FORMAT:  inis  report  presents  selective 
Information  on  an  object  (object-name,  DESCRIPTION,  SYNONYM, 
KtYwOROS,  ATTRIBUTES);  a  subset  of  the  information 
presented  in  tne  Formatted  Problem  statement  report. 
I  BLOCKS  12,  14] 

Dynamic  interaction  (5.1) 

MATRIX  format:  Shows  system  sequencing  and  dynamic  states, 
tnat  Is,  functional/control  flow  and  events/conditions. 
Similar  Information  Is  presented  In  tne  Process-Cnaln 
report,  but  this  reoort  provides  a  matrix  representation  and 
provides  completeness  ano  consistency  diagnostics.  [BLOCKS 
iu  ,  i  i  ,  Mi 

Element  Process  Analysis  Hepoit  (4.2)15.1) 

TABLE  k  MATRIX  FORMAT:  Aids  analysis  ot  Interaction  oetween 
system  data  and  processes.  Designed  to  accompany  tne 
Element  Process  Usage  Report.  lblucks  8,  14J 
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Element  Process  usage  Report  (4.2)  0.1) 

TABLE  c,  MATRIX  FORMAT:  Sho»s  interaction  oet*een  lowest 

level  data  structure  objects  (usually  ELEMENTS)  to  lowest 
level  PROCESSES ;  consistency  and  completeness  cnee* ing 
determines  tnat  eacn  PROCESSES  interacts  witn  some  system 
data.  Aids  in  checKtng  tr  t  redundant  data  structures.  Hay 
be  used  in  conjunction  with  tne  Element  Process  Analysis 
Report.  (BLOCKS  4,  14] 

extended  Picture  Report  ( i .2 )  (4 .  2 j O .  l ) 

GRAPHIC  FORMAT:  A  graphical  network  showing  structures  for 
system  data  or  activities  (PROCESS£S/INlEF.FACt.S)  ana  data 
flow  into,  within,  and  out  of  tne  target  system.  (BLOCKS  6, 
12,  1 4  J 

Formatted  Problem  Statement ( J . 2 ] ( 4 . 2) ( b. 1 ) 

NARRATIVE  s.  outline  format:  Lescrioes  an  ODject  ana  its 
relatlonsnips  to  all  other  ODjects,  and  otner  descriptive 
entries  about  tne  ooject.  Provides  a  complete  display  of 
all  Information  about  a  given  object  (l.e.,  a  complete 
specification  of  computer  maintained  information  on  tne 
object),  formatted  in  tne  same  manner  as  it  would  have  been 
originally  entered  into  the  data  oase.  See  also  Structure 
Report  version  3.2X.  (Ail  oLUCKSJ 

Frequency  Report  (3. 2) (4.2) (b.  1) 

LISTING  FORMAT:  Presents  system  performance  (HAPPENS 

statements)  relative  to  specific  Intervals.'  Aids  checking 
ail  ODjects  related  by  frequency,  understanding  the  various 
parts  of  the  system  with  respect  to  frequency,  and  tne 
amount  of  Input/output  to  be  handled  by  the  target  system. 
(BLOCKS  5,  12,  14] 

Function  Flow  Data  Olagram  o.l) 

GRAPHIC  FORMAT:  Presents  a  single  activity  (PROCESS  or 
INTERFACE)  centered  on  tne  (die  witn  all  data  objects 

flowing  into  the  activity  on  tne  left  and  all  outputs 

flowing  from  t  icnvity  on  trie  r  i  •:  n  1 1  A'lii'i  'UTi-T-  an- 
SKNUNTMS  are  optionally  displayed.  oiiyntly  different 
presentation  in  tne  Picture  Report  and  Process  Summary 
Report.  (BLOCKS  4,  14] 

Identifier  information  Report  (3.2) 

Identifier  Analysis  Report  (4. 2)0.1} 

MATRiX  FORMAT:  Snows  all  information  based  on  the  use  of 

identifiers  for  entities,  INPUTS,  and  do  1  PUTS;  aias  in 

completeness  and  consistency  checking.  (BLUCK  laj 
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Keyword  In  Context  (K* 1C )  Report  (3.2}(4.2)(t>.l) 

listing  format:  Presents  logical  qrouplng  ot  object  naits 
and  permutations  ot  names  as  maintained  In  tne  data  oase; 
used  for  consistency  checking  or  to  locate  object  names  *ne;i 
only  part  ot  the  name  is  known  or  assumed.  I bLOCK  1-1] 

Layout  Report  (5.1) 

NARRATIVE  s,  OUTLINE:  A  report  snowing  tne  layout  comment 
entries.  [BLOCK  14] 

List  Cnanges  (4.2H5.1) 

LIST  FORMAT:  Shows  time  and  date  of  each  cnange  to  tne  aata 
base  and  tne  modifier  command' used;  similar  information  is 
available  as  an  output  option  with  Name-List  ana 
Formatted-Problem-Statement  Reports.  Useful' in  management 
ot  tne  data  oase.  See  also  Data  Base  Status  report  revision 
count.  [BLOCKS  14,15] 

Name-Gen  (3. 2] 

Name-Selection  (4.2H5.1J 

LIST  format:  This  is  a  report  command  wnicn  generates  a 
tile  ot  object'  names  from  tne  data  base  using  a  user-aerinea 
selection  statement.  Used  to  prepare  a  list  or  names  to  oe 
used  as  Input  for  generation  ot  other  reports.  see  commanu 
parameter  description  (Input-Source]  for  most  reports.  [Ail 
BLOCKS J 

Name  List  ( 3 .2) ( 3. 2X) ( 4. 2] (5. 1 ] 

LIST  FORMAT:  Lists  all  names  (ordered  alphabetically  or 
grouped  by  object  type)  in  the  data  base  along  with  tne 
designation  of  type,  synonyms  and  sources  u.2X  only]. 
Useful  as  a  directory  and  provides  alphabetical  grouping 
wnicn  is  useful  in  checking  on  conventions  in  naming  objects 
sucn  as  the  use  of  prefixes  in  the  object,  name.  [All 
bbOCKSJ 

Picture  Report  (3.2)14.2)15.1) 

GRAPHIC  FUHMAi:  snows  a  single  object  (IN it Hr aCc  ,  PkOCcoo, 
SET,  INPUT,  OUTPUT,  GROUP/ CLEMENT)  and  its  immediate 
structure  and/or  data  flow.  Useful  for  nign  level  graphics 
(snapshots)  of  system  requirements  ana  can  be  useful  m 
structured  walkthroughs  as  a  communications  media  between 
analyst  and  target  system  user.  Usea  for  completeness  and 
consistency  checking.  See  also  Function  Flow  Data  Diagram, 
and  Process  Summary  Report.  [blocks  4,  6,  B ,  10,  12,  1 4 j 
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Print  Requirements  Report  (3.2X) 

LIST  FORMAT:  A  specification  document  snowing  system 

functions  (PROCESSES)  and  constraints  presented  in  tne  order 
of  tne  hierarchical  structure  of  functions.  me  automated 
specification  document  Includes  narrative  text 

(.comment-entries)  In  assrclacion  with  tne  functions  and 
constraints  whicn  tney  descnoe.  Tne  report  is  used  as  an 
interface  document  between  tne  requirements  engineer  and  tne 
target'  system  user  and/or  to  provide  intermediate  and  final 
documentation  Cspeclf icatlons)  of  tne  functional 

requirements  of  tne  system.  me  report  is  functionally 
equivalent  to  DoD  Standard  7935, 1-S  ana  MIL-5TD-49U 
specification  requirements!  [BLOCK  12). 

Process  Chain  Report  (3.2) (4.2) (5.1) 

GRAPHIC  FORMAT:  Shows  system  sequencing  and  dynamic  states; 
that  Is,  f unctlonal/control  flow  and  events/conditions.  A 
pictorial  network  of  dynamic  relationships  Detween  objects 
such  as  PROCESSES,  EVENTS,  CONDITIONS,  INPUTS,  OUTPUTS.  The 
Dynamic  Interaction  Report  provides  similar  information  In  a 
matrix  format.  [BLOCKS  10,  H,  12,  14) 

Process  Input/Output  (3.2) 

Process  Summary  (4.2)(5.1) 

STRUCTURED-LIST  FORMAT:  Shows  a  list  of  PROCESSES  followed 
by  any  description  of  the  PROCESS  and  inputs  and  OUTPUTS  of 
each  process.  Useful  in  providing  a  general  description  of 
the  target  system  PROCESSES  and  associated  INPUTS  and 
OUTPUTS.  Similar  information  provided  by  tne  (unction  Flow 
Data  Diagram  ana  Picture  Report.  [BLOCKS  a,  12,  14) 

Punched  Comment  Entries  ( 3 . 2 ) (4. 2) [ 5 . 1 ) 

LIST,  NARRATIVE  &  OUTLINE  FORMAT:  Snows  narrative 

descriptions  (comment-entries)  about  an  ob)ect?  alas 
completeness  and  consistency  checking.  [BLuCK  14] 

Relation  Structure  (4.2)(5.i) 

TABLE  s  MATRIX  format :  Presents  data  structure  information; 
used  oy  requirements  engineers  for  completeness  and 
consistency  checking  of  the  loqieal  data  structure  moael; 
used  by  design  engineers  to  derive  alternate  design 
structures  for  the  target  system  data  bases.  (BLOCK  14J 

Requirements  Traceability  Analyzer  (3.2X) 

TABLE  FORMAT:  This  report  compares  one  data  case  to  another 
by  tracing  requirements  (Objects)  from  one  oata  base  to 
another.  The  trace  is  performed  in  botn  directions, 
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forwards  and  backwards.  Tne  traceaDlllty  is  performeu  using 
tne  TRACcKtY  reiatlonsnlps  In  one  data  Dase  to  an 
object-name  (usually  a  source  document  paragrapn  number, 
l.e.,  an  identifier  for  tne  source  of  tne  requirement)  in 
another  data  base.  Requirements  wnlch  do  not  trace  eitner 
forward  or  oackward  are  listed.  The  main  report  displays 
tne  requirement  (object  -name)  of  one  data  base  on  tne  left 
side  with  tne  requirement  ( od ject-name)  in'  the  second  data 
base  presented  on  the  left  side.  Tne  sources  of  tne 
requirements  are  also  displayed.  This  report  is  useful  in 
tracing  requirements  from  one  data  Dase  to  another. 
Applications  include  tracing  higher  level'  requirements 
represented  In  one  data  base  model  to  the  allocated 
requirements  as  represented  in  the  second  data  oase  moael. 
This  report  is  a  concise  presentation  of  tne  traceability  of 
requirements  and  provides  completeness  analysis  of  tne 
traceability  of  requirements  from  one  system  moael  to 
anotner.  (BLOCKS  13,  14,  15] 

Resource  Consumption  Analysis  (3.2H5.1) 

TABLE  &  MATRIX  FORMAT:  Displays  resources  consumed  by  a 
PROCESSOR ;  used  by  design  engineers  in  evolving  alternative 
designs  in  terms  of  resources  used.  (BLOCK  14J 

Security  Analysis  Report  (4.2)15.1] 

LIST,  MATRIX,  NARRATIVE  i.  OUTLINE  FORMAT:  Displays  security 
information  about  the  objects;  used  to  maintain  consistency 
In  defining  tne  oojects  that  are  of  a  classified  nature  and 
are  to  be  factored  Into  tne  design  of  in  tne  target  system. 
(BLOCK  14] 

Structure  Report  ( 3 . 2) ( 3. 2X ) (4 .2 )  (5. l ) 

STRUCTURED-LIST  FORMAT:  Displays  hierarchies  of  system 
objects  where  tne  levels  of  Indenture  represent  tne 
hlerarcny  of  the  objects.  Hierarchies  can  be  displayed  to 
represent  system  structure,  system  fiow,  ano  dynamics. 
Hierarchies  are  based  on  tne  relationships  defined  between 
tne  objects  such  as  subpart/part,  consist/contained, 
receives/ received,  etc.  The  report  is  useful  in  evaluating 
tne  consistency  and  completeness  of  system  hierarchies. 
Version  3.2/  has  user  options  whlcn  alio*  a.ioitionai 
information  about  PHUCESSES  to  be  displayed  immediately 
after  eacn  PROCESS  in  tne  report.  Options  include  the 
display  of  data  and  control  flow  reiatlonsnlps,  and  memo, 
tracekey,  and  source  information.  In  effect  tne  3.2X 
extensions  combine  some  aspects  of  the  Formatted  Problem 
statement  Report  into  tne  structure  Report.  This  enhances 
tne  utility  of  the  Structure  Report,  since  more 
Informational  value  Is  provided  m  a  single  report  as  an 
option'to  tne  user.  (BLOCKS  4,  5,  t>,  8,  y  10,  U,  12,  14] 
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Suuset  Analysis  Report  (4.2)(S.l) 

MA1R1X  FORMAT:  Displays  information  about  atTB,  such  as 
nlerarcnical  structure  t-using  SuUSETS/SUbSET)  and  tne 
interaction  of  SETS  to  other  SETS  aiony  with  INPUTS, 
OUTPUTS,  and  ENTITIES  which  make  up  tne  SEI.  Alas 
consistency  and  completeness  cnecKing  of  logical  system  aata 
structures.  [BLOCK  14) 

unit  Structure  (b.l) 

STRUCTURED-LIST  FORMAT :  Displays  hlerarcny  ot  system  unit 
object  as  defined  By  the  EQUIVALENT  statement.  Provides 
some  automated  completeness  and  consistency  cnecking. 
[BLOCK* 14) 

Utilization  Analysis  Report  (4.2KB.1) 

STRUCT  UREO-LIST  s.  MATRIX :  Displays  information  about 
PROCESSES  such  as  tne  UTILIZES  structure,  and  tne 
interaction  between  PROCESSES  Cvia  subpart,  utilizes)  in  a 
matrix  format.  Aids  checking  the  consistency  ana 
completeness  of  the  PROCESS  structure.  [BLOCKS  10,  14) 
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APPENDIX  I) 

EXAMPLE  AnALXZEK  KEPUHXS 


The  following  11  figures  nave  been  selected  from  a  variety  of 
Loglcon  requirements  engineering  projects  to  illustrate  some  of 
tne  reports  described  in  tnis  guidebook.  These  reports  were 
genereated  using  version  3.2X  of  psl/psa  (i.e.,  CADSAI : 
URL/UR A ) .  The  figures  Included  are  as  follows: 

Figure 

1 

Input-PSL  As-Is  Source  Listing 

Figure 

2 

Data  Base  Status  report 

iLoglcon  Extension) 

Figure 

3 

Structure  Report 

CLogicon  Modified) 

Figure 

4 

Process  Chain  Report 

Figure 

b 

Data  Process  Report 

Figure 

6 

Contents  Report 

Figure 

/ 

Extended  Picture  Report 

Figure 

8 

Name-Gen  &  Formatted  Problem  Statement  Reports 

Figure 

9 

Requirements  Traceability  Report 

(Loglcon  Extension) 

Figure 

10 

Formatted  Problem  Statement  report 

Figure 

11 

Print  Requirements  Report 

(Loglcon  Extension) 

no  >prc  process-cartographlc-data; 

3ii>srcs-i.O,  s-J.i; 

312  >aesc; 

J1J  >Ine  Clustered  Carto  Processing  System  CCPS),  will  accept  digitize 


LOGICON 


o  t~ 

c  o 
*  a  *4 
*J  ro  . 

H  U  U 
O'  V 
vl  O  £ 
v>  m  u. 
U  k  o 
O  .*M 

o  o 


a  %+  ai 
o  a- 
^  m  o 
*j  u 

'H  i  Q. 

O 

C  H  fll 

o  -h  c  •- 
<0  *-* 

VI  CD 

CT3  CO 
O  C  --H  \J 

H  *0  .  * 

M  0) 

’  <0  *.  *J  4> 

f  C?  <0  w 

U.  C  O  <0 
OH  A  •* 

*H  V  «  *  VI 

w  -»  c  n)  vi  c 

cow  CO 
4l  *0  •  O  —4 

h  C7>  O  H  W 

*-»  U  C  —  W  <0 
H  H  o  >1  ID  O 
W  jj  *J  H  U  H 

3  UJflC  H  w  H 

o  e  U  Q.  —♦  -H  o. 

h  o  J3  d  ^  a  a 

U  *J  C  w.  O  Q.  fl> 

rO  •  3  4>  CT>  <0  • 

>  ro  -O'  O  Q.  «  V) 

il  <0  M  O 
tH  E  o  M  O  O  H 

U.  U  *j  *0  I  wH  C 

no  J  n  c  a 

L«  >  CL  <0 

Lw  U  O  43  H  (XI  L* 

a i  n  h  c  v  u  o 

a  a  v*  u  o  o  o 
o.  <o  o  *-* 

k  «  t  a  U  li 

<U  -*J  C  -H  Cl  L,  ro  . 

M  -H  O  V  fl  O 
it)  -H  C  C  O  I 

tj  ai  u  o  h  i  a. 

»J  u  *  o  o 

u  q  in  v)  c  n  m 

itJ  O  U  3  t) 


•%  ro. 

VI  tl 

C  ro.  * 

O  -  O  O 

<0  •  »  *w  C  W 

U  U  M  OH  9 

<0  ro  a  C  *J  c 

U  O  UH  H-T 
H  |  I  W  O  W 
H  H  T3  H  41  VI 

Q.  ro  41  TJ  I  Cl 

a  h  u  u  v  u 

<0  H  b  I  >  O 

I  (Ml  UH  v 

vi  -h  >  h  v  a. 

u  a  c  u  u  i 

-HI  O  ro  fl  U 

C  W.  U  t  1<  :5 

il  1  I  O  Cl  Cl 

m  v  v  v  v  v 
\+  Cl  O  3  C  3 
O'  -4  41  4»  -H  O 
O  *H  U.  I  I  | 

kJ  I  4*  C  E  n 

l-.MOW-.VwU. 
<0  U  O  O  O  O 

O  4>  V.  <ur  %4 

I  U  H  U  U  h 

O  O  ro  41  Cr  4i 

o  u  >  a  aa 


41  *H  41  -4  . 

C  -H  *J  O 

*+  (0  G  C  B 

H  >  H  H  tfl 

A  A  A  A  A 


a  a 

o  u  o 

3  u  3 

vi  a  in 

A  A  A  A  A 


A  A  A  A  A 


>» 

U 

41 


ro  • 

> 

10  • 

e 

o 

u. 

'M 


10  -VI 
*J  M 

*o  -<o . 

O  £ 

W.  i 
-4  O 
10  *M 


-t  c  <0  • 

ro-  *H  > 

I 


<0  U  -H  • 

M  o  I 

H  U  H- 

QI  a  ro. 

H  I  I 

O  U  vi 

I  3 

m  n. 
hi  r  h 

41  -H  • 

c  n  • 


ro-  «w 
41 

c  a.  * 
h  m  *j  v 
j->  e  m 


o 
c  o»  » 

ro  ro  41  U. 

E  d  O 
VI  l  CM 

e  c  <o  i 

4)  O  C.  4) 

o 


E  U  C  u  H 

Ih  4)  3  <0  »0 

e  a  rs  c  *j 


u  i  t  u 

O  C  41  41 
H  o  (1  v 


ro 

TJ 

'  I 

rp  tl 

u  a 
<o  o 

p  i 


v-.lt/lt-. 


u  c  u 

U  >»  u 

CX  VI  VI 

AAA 


UVIMXrOCikJtiw 

h  >  3  v  p  a  3  I  I 
3  VI  CL  I  I  -O  a  O  O 

tr  cfviMc  *-»*-> 

41  C  H  v*  H 
L-.  O  I  VI  H  VI  I  *0 

-H(0-l  I  VMI.U  L  y  W 
W  pi  W  ID  Ifl  V  |  4*  I  VI 

«H  U  4J  E  I:  W  <0  D  >  C  C 

VUOXJHOrOCH,TJ 
rH  R  I  |  I  I  41  O  C  U. 

HCCCCCuUtiu 
0*00000 
o .  o. 


to 

X 

—  u 

o 

VI  41 
41  C 
O  H 
A  A 


•ME  3 

O  vi  v» 

AAAAAAAAAA 


« 

M 

•  *  <0 

£  O 

O  » 

M  41 

0  Q. 

O  t» 

I  M 

tc  | 

a  o 

u  m  •- 

I  MO 

*-*  ro  • 

u.  4.»  o . 

41  I  I 

>  O  «H 

C  to  ro 

O  41  I 

U  V  VI 


O  O 

L.  L. 

a.  vi 
A  A  A  A 


C’H^rN«3iOHv‘4'|.Cin^fwW>OH«'»,^y<tCN3)>DH.N,Oir/l1Or» 

H  -»  rtHHHNNNMMN  N^NN'TI^'V'.wi.w)  H-H  <r  <f  C 


>  ;  )  j  ->  ^ 


)  > 


>  i  >  > 


f  igure  1.  Tne  As-ls  Source  Llstliiq  Is  one  ot  elgr.’  reports  produced  »nen  modltying  tne 
requirements  data  base.  Tnis  example  Is  an  excc  .  i.  trom  tne  language  statements  entered 
tor  the  CPS  using  the  modifier  commano  lnput-PSL. 
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Figure  7.  information  flow  Into,  witnln,  ana  out  cf  tne  target  system  can  t>e  snown  using 
tn<>  extended  Picture  report,  inis  example  fro*  tro  CPS  re;u  l  r  emen  ts  c.n-i  ».ise  (Figure  l) 
s  r  '.,s  tne  flow  of  tour  Inputs  generat’d  tram  a  single  jntfpfaUl. 
cir  t  ographie-col  lect  lon-sy  s  tms .  Tfie  report  continues  to  idultlonil  pages  until  all 
defined  flow  is  presented. 
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Fiqure  8,  By  comolnlnq  tne  features  of  two  report:,  the  analyst  can  locate  and  display 
selected  information  on  a  requirement  wnlch  may  oe  cnahged .  using  tne  Name-Gen  report 
snown  at  tne  top,  a  list  of  functions  (PROCESSES)'  with  a  Keyword  of  tracxlnq  can  oe 
extracted.  Tne  analyst  can  next  produce  a  Format. ed  Proeiem  statement  report  lor  eacn  of 
tne  4  function  names  or  a  single  function  name  sucn  as  tne  report  snown  at  tne  nottom. 
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